Screenshot Generator API: Release Note Images

A screenshot generator API takes a raw capture and returns it framed, padded, and on-brand, without anyone opening a design tool. You build the frame once, mark the image layer dynamic, and pass a screenshot URL per release.

The hard part isn't the framing. It's that screenshots arrive in whatever shape the person capturing them happened to have on screen, and a layout that assumed 16:9 falls apart the first time somebody sends a tall mobile capture. Here's how to make that stop mattering.

If you just need one image today, the screenshot beautifier does it free in the browser. This post is about the release after that, and the fifty after that.

Raw screenshots are never the shape of your frameRaw screenshots are never the shape of your frame

A design's width and height are fixed when you build it. That's what keeps every release image identical, and it's also why the incoming picture has to be dealt with rather than trusted.

Think about what actually lands in that slot over a year: a 2560 by 1440 desktop capture, a 1170 by 2532 phone screenshot, a cropped detail of a settings panel someone took at 800 by 300. One box, three wildly different aspect ratios.

The wrong fix is to stretch the picture to fit. That distorts the very UI you're trying to show off, and everybody can see it. Say what should happen instead.

Imagesize is object fit and its the whole trickimageSize is object-fit, and it's the whole trick

The image layer's imageSize property maps directly to CSS object-fit, so the behaviour is the one you already know from the browser:

For release notes the answer is nearly always contain, paired with a backgroundColor that matches your frame. A tall phone screenshot letterboxes onto brand colour instead of getting its top and bottom sliced off. A wide desktop capture does the same on the sides. Both look deliberate.

{
  "key": "shot",
  "type": "image",
  "dynamic": true,
  "properties": {
    "imageSize": "contain",
    "backgroundColor": "#0F172A",
    "padding": "24px",
    "borderRadius": 12,
    "boxShadow": "0 24px 48px rgba(0,0,0,0.35)"
  }
}

Imageposition decides what survives a cropimagePosition decides what survives a crop

When you do want cover, imagePosition is the focal point, the same as CSS object-position. It's the difference between a crop that keeps the thing you're announcing and one that keeps a sidebar.

• top for anything where the toolbar, tab bar, or page header carries the message.
• center for dashboards, where the content sits in the middle.
• bottom for a capture whose point is a status bar or a result row.

Set it in the design rather than per render, unless your screenshots genuinely vary in where the interesting part sits. One less dynamic property is one less thing a release script can get wrong.

The frame is layers not a filterThe frame is layers, not a filter

The browser chrome, the rounded corners, the shadow: none of that is an effect applied to the picture. It's the design around it, which means it's consistent by construction.

A frame that holds up is usually three layers:

1. A rect at the full canvas as the background, with your brand colour.
2. A second rect as the window, with a border radius and a subtle border.
3. The image layer on top, with padding, its own radius, and a box shadow.

Order matters, because layers paint in list order and the last one wins the pixel. Layout primitives covers that model in more detail. The payoff is that a screenshot from a contributor who has never seen your brand guide still comes out looking like it came from your team.

What a screenshot generator api costsWhat a screenshot generator API costs

One render per image, and re-rendering after you retake a screenshot costs another.

As of September 2026, that's 100 free renders a month, no card. Two release images a week is 8 a month, so a weekly changelog runs on the free tier indefinitely. A platform team shipping release images for six products, several times a week, is closer to 200 a month and lands on Basic at $14.99. Full numbers on the pricing page.

The honest version, and the advice we'd give a friend: if you ship one release image a month, automating this is a waste of an afternoon. Use the free tool. The case for the API starts when the same image gets made every week by someone who'd rather be doing something else.

Wire it into the releaseWire it into the release

The pattern that sticks is generating the image where the release notes already live:

curl -X POST 'https://render.imejis.io/v1/YOUR_DESIGN_ID' \
  -H 'dma-api-key: YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "shot":    { "image": "https://cdn.example.com/shots/v2-4-0.png" },
    "version": { "text": "v2.4.0" },
    "headline":{ "text": "Bulk export, now in one click" }
  }' \
  --output release.png

Drop that in the job that already tags the release. The screenshot URL can point at whatever your CI produces, including an automated capture, so the whole thing runs without a human in the middle.

Where to go nextWhere to go next

Start in the screenshot beautifier to settle the frame, then rebuild it as a design and mark the image layer dynamic. The image component page has the fit and position controls live, dynamic fields covers what to open up, and the API docs have working calls in a dozen languages.