Social cards sit in that odd category of work everyone agrees should be automated and almost nobody automates. The manual loop — open the design tool, duplicate last week's frame, retype the title, export, upload — dies quietly the first week you get busy. It's workflow-engine work, so hand it to a workflow engine. Below: installing the Shotium community node in n8n, wiring the credential, a working RSS-to-image workflow, and the one decision that actually matters here — rendered binary or signed URL.

What you'll need

  • An n8n instance that can install community nodes. Self-hosted works today; we've submitted the node to n8n's verification program, and once that lands it becomes installable on n8n Cloud too.
  • A Shotium account. Sign-in is GitHub or Google OAuth, and a fresh account starts with 100 free render credits — no card involved.

Install the node

Open Settings → Community Nodes → Install in your instance, paste the package name, confirm:

n8n-nodes-shotium

Done — that's the entire install. Three operations ship with the node: Take Screenshot, Generate OG Image, and Generate Signed URL. New to community nodes? n8n's own installation guide walks through the mechanics and the security model.

Connect your API key

Create a key on your account page. It starts with sk_live_ and is shown exactly once, so copy it then and there. In n8n, add a Shotium API credential and paste the key in. The two remaining fields — Signing Secret and User ID (UID) — matter only for the Generate Signed URL operation, and both come from the same issuance as the key itself.

Hit the credential test button before you build anything. Under the hood it calls GET /v1/me, which validates the key without billing a render — the green check is free.

The workflow: new post → OG card

The smallest version that does real work — and the pattern we run against our own feed:

  1. RSS Feed Trigger — point it at your feed (ours is https://shotium.com/rss.xml). Each new item arrives carrying title, link, and friends.
  2. Shotium node — operation Generate OG Image, template Blog, with fields mapped by expression:
    • Title → {{ $json.title }}
    • Author → your byline, e.g. Shotium engineering
    • Site Name → shotium.com
    • Tag → a static label like Engineering, or a mapped category field
  3. Wherever your images live — an S3 upload, your CMS's media endpoint, even a Slack message for review. The rendered card lands in the item's binary field (named data by default), ready for anything n8n can send a file to.

Cards render at 1200×630 — the Open Graph standard size — in PNG or JPEG. All five templates are typed: the node UI surfaces each template's own named fields, so there's no JSON to hand-assemble.

  • Blog — author, site name, tag, avatar URL
  • Product — brand, price, description, product image URL
  • Podcast — show name, episode label, cover art URL
  • Event — date, location, organizer
  • Minimal — title and subtitle, nothing else

Real rendered output of all five — with the exact parameters that produced each card — lives on the templates page.

Binary render or signed URL?

Worth slowing down for, because the two operations carry very different cost profiles.

Generate OG Image renders on the spot and hands your workflow the image bytes. Reach for it when a file has to exist somewhere concrete — a CMS media library, an email template, an S3 bucket you control. One successful render bills one credit; a failed render bills nothing.

Generate Signed URL never calls the API at all. The node computes an HMAC-signed link locally — hence the signing secret — and returns JSON with a url ready to embed:

<meta property="og:image"
      content="https://api.shotium.com/v1/og-image?template=blog&title=Your%20post&uid=...&sig=...">

Nothing renders until a social crawler actually requests that URL. The first hit renders and caches at the CDN edge; repeat hits are cache hits. Your API key appears nowhere in the page — the signature proves only that the parameters weren't tampered with. Change any parameter and the URL changes, which re-renders with the fresh values: data changed, image follows. That's the entire trick behind OG images that update when your data does.

Our rule of thumb: destination is a <meta> tag → signed URL, skip storage entirely. Destination is a file field in some other system → render the binary.

Take Screenshot, while you're in there

The third operation turns any public URL into a PNG, JPEG or WebP — viewport control, full-page capture up to 20,000px, quality settings on the lossy formats. Teams wire it to cron triggers for weekly dashboard snapshots, or run it over a URL list to archive competitor pricing pages. One GET request against a browser we keep warm, patched, and — since it opens strangers' URLs from inside our own infrastructure — aggressively sandboxed.

Practical notes

  • The rate limit is 60 requests per minute per key. Batch runs beyond a few hundred items want n8n's built-in batching or a short wait node.
  • Billing counts successful deliveries only. A render that errors out is our problem, not your invoice's.
  • A 401 on the credential test means the key is mistyped or revoked. Keys are shown once at creation — if one goes missing, issue a new one.
  • Full-page screenshots cap at 20,000px of scroll height.

Every parameter of all three operations is documented in the API docs — signed-URL canonicalization included, if you'd rather implement the HMAC yourself in another language. And if the node helps you build something worth showing — a workflow we should feature, a template we're missing — we genuinely want to see it: contact.