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
Signed render URLs
Put the render in the URL
Mint a signed Renderwolf 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 accountRead the API docs
- No key in the markup
- No temporary bucket
- Cached repeats free
- Never expires, if you want
POST /renderwolf/v1/sign
Authorization: Bearer rw_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.uk/renderwolf/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.
With a signed URL
- Mint a signed URL once, from your server
- Put it in the markup, the tag or the email
- Renderwolf 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
Renderwolf 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. Every identical GET after it is a cache hit and costs nothing.
- Renders meter against the account that minted the URL, under the same hard caps 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.
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.
Questions
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. Renders meter against your quota exactly as a direct API call would, and repeats of the same URL come from cache for nothing.
Can the URL expire?
You choose. Set a lifetime in hours when you mint it, or leave it at 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, Renderwolf 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.
Mint your first signed URL
Create an account, take a key and sign one request. The render is inside your free credits.
250 free credits each month, with no card required, hard usage caps and free cache hits.