Orshot — one credit per image, PDF page or video second, and how the meters work

• Orshot

  This page

  PricingOrshot leads

  • A free starting balance, then monthly subscription tiers that scale by credit allowance
  • One credit buys one image, one PDF page or one second of video, from a single pool rather than separate meters per output type
  • Two further allowances sit alongside the render credits: AI operations and automation runs, each with its own monthly ceiling
  • Overage rates are charged per additional block of credits and fall as the tier rises, so heavy volume is cheaper on higher plans
  • Annual billing is offered at a discount equivalent to two months

• Bannerbear

  PricingOrshot leads

  • A small free trial allowance, then monthly tiers priced per render volume
  • Renders are metered per image, and higher volume tiers reduce the per-render cost
  • AI operations draw on a separate dedicated credit balance rather than the render allowance
  • No multi-page or timed video output, so a document or animation needs a different product

• Placid

  PricingOrshot leads

  • The lowest entry tier of the three established products, with a small monthly credit allowance
  • Unused credits roll over between billing periods, which is unusual in this category and useful for spiky workloads
  • Large or multi-size outputs can consume more than one credit, so the effective cost per asset depends on the template
  • No native carousel object, and video is a more recent addition

• APITemplate.io

  PricingOrshot leads

  • Monthly tiers priced by render allowance, with both a visual editor and an HTML/CSS authoring path on the same plan
  • Renders are metered per output, with batch and multi-size generation supported
  • The HTML path uses a headless browser, which is heavier per render than a canvas-based engine
  • Tiers are structured around monthly quotas plus overage rather than credit rollover

1. Orshot — official site
2. Orshot — image generation API
3. Orshot — rendering documentation
4. Orshot — feature list
5. Orshot — pricing and credits
6. Bannerbear — official site
7. Placid — official site
8. APITemplate.io — official site

Free tier

Yes

Pricing summary

The pricing model is a credit subscription, and the part worth understanding before you compare plans is that there are three separate meters rather than one. Render credits cover the actual output: one credit buys a single image, a single PDF page, or a single second of video, which is the definition that makes this product easy to reason about. A second allowance covers AI operations performed at render time, such as generating text or imagery inline. A third covers workflow automation runs, each with its own monthly ceiling on active workflows, step count and concurrency. A pipeline that renders twenty thousand assets a month is not just a bigger render bill — it is a different combination of all three, and the tier structure reflects that. The tiers themselves are subscriptions priced monthly or annually, named for scale rather than for features: an entry tier sized for single-workspace use with limited collaborators, a middle tier with more credits, more workspaces, deeper isolation and more concurrent automation, and a top tier with the largest allowances and the most workflow concurrency. Overage is charged per additional block of credits at a rate that falls as the tier rises, so high volume is cheaper if you are on the right plan rather than paying overage repeatedly on a small one. Two structural details are worth noting because they differ from the established alternatives. First, video and documents are covered by the same credit pool as images, so there is no second subscription or multiplier for output types. Second, collaborators, workspaces and team seats scale with the tier rather than being priced separately, which matters if you are buying for a team rather than for yourself. There is also an optional per-account monthly charge for publishing renders directly to social platforms, which is genuinely a separate product rather than part of the render allowance. Pricing pages in this category are restructured regularly and the credit definitions are the kind of thing that gets adjusted, so confirm the current tiers, allowances and overage rates on the official pricing page before you commit to a plan.

Reviewed on 19 September 2026 · Orshot — pricing and credits

• A visual editor where the canvas is the API surface

  Templates are built in a studio editor and every element that should vary is exposed as a parameter. That is the central mechanism of the whole category, and the quality of the editor determines how much of your design work survives the translation from Figma. Inline text styling, layer groups, smart stacking that pins elements to each other, and text autofit that shrinks long values rather than letting them overflow are the details that decide whether a template can handle real data or only the sample.

• Import from Canva and Figma rather than rebuilding the design

  Existing designs can be brought in from the two tools most teams already design in, or from several other template formats. This is the feature that most shortens the setup for a team with a brand system already — importing a finished design and layering parameters onto it is a different order of effort from redrawing it on a new canvas, and it is the difference between adopting a rendering API in an afternoon and in a sprint.

• One credit for an image, a page or a second of video

  Images, multi-page documents and video all render from the same canvas and draw on the same credit pool, with PNG, JPG, WebP and AVIF output, transparency where the format supports it, and a scale factor for high-density output. Multi-page templates produce carousels and paginated documents in one request, with the option to ask for specific pages. It is the part of the product that is most obviously different from the established alternatives, and it removes a whole planning exercise from the pipeline.

• A REST endpoint plus SDKs in the common languages

  Rendering is a single authenticated request carrying a template ID and the values to override, and there are official SDKs for Node, Python, Ruby and PHP alongside the raw HTTP interface. The response can be a hosted URL, base64 data or a binary stream, which covers the three places rendered output usually needs to go — a web page, an email, or a file download — without a second round trip.

• No-code and agent integrations out of the same template

  The same template ID is callable from automation platforms, spreadsheet add-ons, a workflow builder, a CLI and an MCP server for AI agents. The practical value is that the marketing team can drive a template from a spreadsheet while the engineering team calls it from code, and both produce identical output rather than two drifting implementations of the same design.

• Bring your own storage, or signed URLs

  Renders can be written straight to an S3, R2, Dropbox or Google Drive destination, with the vendor stating it keeps no copy when you do. Alternatively a signed, time-limited URL can be returned. For a team with retention requirements, a customer-facing document pipeline, or simply a preference not to accumulate another vendor holding its assets, this is the line that ends the evaluation in the product’s favour.

• AI operations and publishing as separate, optional layers

  A prompt suffix at render time can generate text or imagery inline, drawing on a separate AI credit allowance rather than the render pool. Renders can also be published to social platforms in the same call for a per-account monthly charge. Both are genuinely useful and both are separate meters, so the honest framing is that they are extensions of the core product rather than part of what a base tier includes.

• Workflows and a no-canvas automation builder

  A trigger, a data source, a template and a destination, assembled without code, with presets for common recipes such as a spreadsheet driving a carousel or a bulk certificate run. This is a different product from the API in the sense that it needs its own subscription dimension — automation runs are metered — but it is what lets a non-technical owner operate the pipeline once it exists.

1. 1

   Start from the worst-case data, not the sample

   The single most common failure in template automation is a template that looks perfect with short placeholder text and breaks the first time a real customer has a forty-character name. Design against the longest, shortest, emptiest and least predictable values you will actually receive, and use the autofit and pagination features to absorb the rest. A template validated only on its own preview is a template that will fail in production.

2. 2

   Decide the storage question before the first render, not after

   Where rendered output lives determines a surprising amount of the architecture: whether URLs expire, whether you need a CDN in front, what your retention policy has to say, and whether a customer-facing document is sitting on a third party’s servers. Routing to your own bucket or returning signed URLs is a one-line change at the start and an infrastructure project once a pipeline is live.

3. 3

   Map out all three meters against your real volume

   Render credits, AI operations and automation runs are metered separately, so a workload that is cheap on renders can be expensive on automation runs if the pipeline triggers per event rather than in batches. Work out the monthly shape of each meter from the volume you actually expect, then pick the tier — and remember that overage is charged at a rate that falls as the tier rises, which makes under-buying look cheaper than it is.

4. 4

   Keep one template as the source of truth across code and no-code

   The same template ID is callable from an SDK, a spreadsheet, a workflow tool and an agent, and the temptation is to let the marketing team build its own version for convenience. Resist it. Two implementations of the same design drift within a quarter, and the drift is invisible until a customer receives an off-brand asset. One template, several callers, is the pattern the product is actually shaped around.

5. 5

   Test the failure modes, because a render is a request that can fail

   Templates fail on bad input: a missing image URL, a field that arrives as a number instead of a string, a font that has not finished loading, a scale factor that produces an enormous file. Build the error handling before launch rather than after the first batch, and prefer a webhook or a queue over a synchronous call when the volume is high enough that a timeout would cost you a batch rather than a single asset.

6. 6

   Verify a render visually against the template, not just for a 200 response

   An API that returns a URL has succeeded at transport, not at design. The composition can still be wrong — text overlapping a logo, an image cropping badly at an unexpected aspect ratio, a long value pushing a fixed element off-canvas. Spot-checking a real render at the extremes of your data is the step that catches a class of bug no status code will report.

• Product and growth engineers generating assets from data

  The clearest fit: someone who needs social cards, ad variants, personalised images or transactional documents produced from records rather than designed individually. The REST endpoint plus SDKs plus a template playground is the shortest path from a design file to a working endpoint, and the flexibility of returning a URL, base64 or binary means the output can go wherever it needs to without a second hop.

• Teams whose output is not all images

  This is where the single-meter model pays off most. A pipeline that produces a PDF document for one workflow and a short video clip for another, both from the same design system, would mean two subscriptions or a multiplier elsewhere. Here it is one credit per page or per second out of the same pool, which means adding a format does not mean renegotiating the plan.

• Marketing teams driving templates without engineering involvement

  Once a template exists, the same template ID can be called from a spreadsheet, a workflow tool or a preset recipe, so the people who own the content can run the pipeline without filing a ticket. The design stays under the designer’s control because the template is the design, and the parameters are the only thing being changed.

• Anyone whose renders must not accumulate in a vendor’s storage

  Routing output to your own bucket, or returning signed and expiring URLs, addresses retention and data-residency questions that come up in every serious evaluation of this category. If you are rendering customer documents, invoices or anything with personal data in it, this capability moves from nice-to-have to the deciding factor.

• Teams already working through a workflow tool or an AI agent

  The integration surface is the broadest here: automation platforms, spreadsheet add-ons, a CLI and an MCP server so an agent can call a render directly. For a team that has moved its operational work into one of those environments, a rendering API that only speaks REST is a small integration project, and one that already speaks the same language is an afternoon.

A template rendering service, not an image model

The output is a designed layout filled with data, not pixels invented from a prompt. That distinction decides most matches: if you need a photorealistic image of something that does not exist, this is the wrong category of product. The AI layer here augments a template — generating the text inside a headline or an image into a defined frame — and it is metered separately from rendering for exactly that reason.

Three meters rather than one, and all three have ceilings

Render credits are the primary meter, one per image, PDF page or video second. AI operations draw on a separate allowance. Automation runs draw on a third, with limits on active workflows, steps per workflow and concurrency rather than only on total volume. The practical implication is that a pipeline can hit a ceiling on automation while its render allowance is barely used, so the tier decision has to consider all three.

Credit overage is priced per block and falls as the tier rises

Renders continue past the monthly allowance and are billed as additional blocks of credits, at a rate that is lower on the higher tiers. That structure rewards buying the tier that matches your volume rather than the smallest tier and absorbing consistent overage — a detail worth modelling rather than assuming, because the difference accumulates.

Server-side rendering, with an optional path to your own storage

Rendering happens on the vendor’s infrastructure, so template content and render payloads leave your systems. The mitigation is configurable: output can be written directly to your own S3, R2, Dropbox or Google Drive destination, where the vendor states it keeps no copy, or returned as a signed URL that expires. Workspace isolation and role-based access are available on the higher tiers for teams that need them.

A newer product in a category with an established leader

The company is younger than the tool that defined this category, and independent comparisons in 2026 describe it as a cheaper alternative that is worth watching but less proven. That is not a defect — it is what buying on price from a new entrant means — and the practical consequences are a smaller body of public troubleshooting, fewer edge cases already solved, and a roadmap that is still being shaped. Budget for that when you weigh the per-render saving.

What it does not do

It does not replace a design tool — templates still have to be designed, here or elsewhere. It does not provide a native carousel structure, so slide sequences are composed as multi-page renders with the layout handled by the template. It does not generate general-purpose imagery from text as its primary function. It does not offer HTML and CSS as the authoring format, which is a different class of product. And it does not eliminate the design discipline a template needs: a parameterised canvas is only as robust as the worst data you feed it.