Does the URL expose my API key?

No. The key mints the URL and never travels in it. The URL carries the request parameters and a signature over them, so a visitor cannot change the target, the size or the template and have it still render.

Who pays for renders through a signed URL?

The account that minted it. A render through the URL counts against that account's usage exactly as a direct API call would, and a repeat served from cache counts nothing.

You choose. Without a lifetime it lasts 30 days; set one in hours when you mint it, or set it to zero for a URL that does not expire, which is what you want for an og:image that has to keep working.

What can a signed URL render?

A screenshot of a URL, or a stored template with the variables you pass. That covers the two cases where the asset has to exist at a URL: page captures and generated images.

Can I use one in an og:image tag?

Yes, and it is the case the feature exists for. Crawlers fetch the URL, Ironfang Render renders it, and the image is there without your application generating and storing anything first.

Can I put one in an img tag or an email?

Yes. It is an ordinary HTTPS GET that returns an image, so anything that loads an image can load it.

Put the render in the URL

Mint a signed Ironfang Render URL and use it directly in a page, an og:image tag or an email. It renders on the first request and caches after that, so your application never generates, stores or serves the asset itself.

Create a free account Read the API docs

No key in the markup
No temporary bucket
Cache hits count nothing
Never expires, if you want

POST /render/v1/sign
Authorization: Bearer if_live_...

{
  "kind": "image",
  "template": "og-card",
  "vars": { "title": "Why we own our hardware" },
  "width": 1200,
  "height": 630,
  "ttl_hours": 0
}

<meta property="og:image"
      content="https://api.ironfang.com/render/v1/
               results/0/8a13c09e4f22..." >

What it replaces

The rendering plumbing you no longer write

Generating an image for every page is mostly infrastructure. A signed URL removes the infrastructure and keeps the image.

Without it

Run a rendering worker, or queue a job and poll it
Write the result somewhere public and keep the bucket alive
Invalidate and regenerate when the underlying content changes
Keep an API secret in whatever generates the markup

With a signed URL

Mint a signed URL once, from your server
Put it in the markup, the tag or the email
Ironfang Render renders on the first GET and caches the rest
No key in the page, no bucket, no worker

How it works

Signed once, rendered on demand

Your server holds the key. The page holds a URL that cannot be tampered with.

Your server mints a URL

The URL goes in the markup

Ironfang Render renders on GET

The signature covers the parameters, so the target, size and template cannot be edited by whoever holds the link.
The first GET renders. An identical GET served from cache counts nothing; one that renders again counts like any other render.
Renders count against the account that minted the URL, within the same monthly usage limit as the rest of your usage.

Where it fits

Two kinds, and the places they belong

A signed URL renders a page capture or a stored template. Those are the two assets that usually need to exist at a URL.

Open Graph and social cards

Design one template, mint a URL per page with the title, author or price as variables, and put it straight in the og:image tag. Change the template and every card follows, with no rebuild and nothing to purge.

Template rendering in the docs

Page captures in place

Embed a live capture of a page in a dashboard, a status board, a digest email or a directory listing. The image is current when it is fetched rather than as fresh as your last cron run.

Before you integrate

The details that decide whether this fits, without reading the whole reference first.

Does the URL expose my API key?: No. The key mints the URL and never travels in it. The URL carries the request parameters and a signature over them, so a visitor cannot change the target, the size or the template and have it still render.
Who pays for renders through a signed URL?: The account that minted it. A render through the URL counts against that account's usage exactly as a direct API call would, and a repeat served from cache counts nothing.
Can the URL expire?: You choose. Without a lifetime it lasts 30 days; set one in hours when you mint it, or set it to zero for a URL that does not expire, which is what you want for an og:image that has to keep working.
What can a signed URL render?: A screenshot of a URL, or a stored template with the variables you pass. That covers the two cases where the asset has to exist at a URL: page captures and generated images.
Can I use one in an og:image tag?: Yes, and it is the case the feature exists for. Crawlers fetch the URL, Ironfang Render renders it, and the image is there without your application generating and storing anything first.
Can I put one in an img tag or an email?: Yes. It is an ordinary HTTPS GET that returns an image, so anything that loads an image can load it.

Less to operate. More to ship.

Mint your first signed URL

Create an account, take a key and sign one request. The render is inside your free allowance.

Create a free account Read the API reference

500 free screenshots each month, no card required, and cache hits count nothing.