Email Preview API.

Render your real email across 50+ real email clients and devices via REST: create a spam-check, send the message, request the previews for that test, then read back pixel-accurate renders as JSON, each captured from a live client in light and dark mode. The same renders are exposed as MCP tools, so AI agents can run an email rendering test in plain language.

POST /ext/v2/client-previews

curl -X POST https://api.unspam.email/ext/v2/spam-check \
  -H "Authorization: Bearer $UNSPAM_TOKEN"

# response (201)
{
  "id": "2Bl8rzTFN6VV",
  "inbox_address": "test-xyz@check.unspam.email"
}

# send your email to inbox_address,
# then read the previews per device.

curl -X POST https://api.unspam.email/ext/v2/client-previews \
  -H "Authorization: Bearer $UNSPAM_TOKEN" \
  -d '{"email_source":"spam-check","source_id":"2Bl8rzTFN6VV"}'

# then poll the preview by its own id
curl https://api.unspam.email/ext/v2/client-previews/3f9a2c8e \
  -H "Authorization: Bearer $UNSPAM_TOKEN"

# response (200)
{
  "status": "completed",
  "previews": [
    {
      "device_key": "aol_chrome",
      "device_name": "AOL (Chrome)",
      "status": "completed",
      "original": "https://…/original.png",
      "thumbnail": "https://…/thumb.jpg"
    }
    // one entry per device, 50+ in total
  ]
}

The preview calls and the whole suite, on one key.

The email preview API shares its token, rate limits, and billing with the spam-check and inbox-placement APIs, so rendering plugs into the same integration you already run.

Client Previews

POST /client-previewsYour email rendered in 50+ real clients and devices, light and dark, as image URLs you read back by preview id.

Device Catalog

GET /client-preview-devicesEvery renderable client with its key and category, for building the devices filter.

Spam Tests

POST /spam-checkThe test that carries the previews: score, sender forensics, and per-check breakdown in the same result.

MCP Tools

create_client_previewThe preview endpoints as MCP tools for Claude, Cursor, ChatGPT, and any remote-MCP client.

Why teams wire previews into their pipeline.

Real client captures, not simulations.

Every preview is your email opened in an actual copy of the client and device, then screenshotted. No CSS transforms, no browser emulation: the image you get is what a subscriber on that client sees.

Light and dark on every client.

Each of the 50+ clients renders in both modes, so one call returns 100+ images and the inverted logo or unreadable dark-mode text shows up in your pipeline, not in production.

Scope renders with the <code>devices</code> parameter.

Pass devices with keys from the catalog to render only the clients you care about (just iOS Mail, just every Outlook), or omit it for the full set. Newly requested devices come back pending; poll until each is completed.

MCP tools for AI agents.

The preview endpoints ship as MCP tools (create_client_preview, list_client_preview_devices) on the Unspam MCP server, so Claude, Cursor, or any MCP client can pull real client renders mid-conversation.

What the preview endpoints return.

Real client screenshots as JSON: one entry per device, each captured from a live client in light and dark mode.

Pixel-accurate previews for any test.

POST /client-previews with email_source set to spam-check and the test id as source_id starts the renders. GET /client-previews/{id} then returns a top-level status and a previews[] array with one entry per device: device_key, device_name, per-device status, and URLs for the original and thumbnail renders.

original and thumbnail stay null until that device flips to completed, so a simple poll loop drains the whole set. Most devices land within about a minute.

gmail · light

outlook · dark

iphone

A device catalog you can filter against.

GET /client-preview-devices lists every renderable client with its device_key, display name, and category (DESKTOP, MOBILE, WEB). Cache it, show it in your own UI, or use it to build the devices filter for the render call.

Filtering is about signal, not quota: one preview request spends one device preview whatever the number of devices, so a CI job that runs on every template change can render just the three Outlook versions it cares about and review only those.

AOL (Chrome) category: WEB
Outlook 2019 category: DESKTOP
Apple Mail category: DESKTOP
iOS Mail category: MOBILE
Android category: MOBILE

The same previews, callable by AI agents over MCP.

Connect the Unspam MCP server over OAuth and your assistant gets the preview tools next to spam checks and inbox placement. Ask it to render the campaign and flag anything broken in Outlook dark mode, and it chains the calls itself.

MCP support means your agent workflows can check renders from real clients without a human opening a dashboard.

Render this campaign create_client_preview
Which clients can you render? list_client_preview_devices
Run the full check start_spam_check

How the email preview API works in four steps.

Previews ride on the spam-check flow: create a test, send your email to the inbox address we return, request the previews for that test, then read the renders per device.

01
Create a spam-check

POST /ext/v2/spam-check with your bearer token. The 201 response hands back a test id and a unique inbox_address.
02
Send your email to the inbox address

From your transactional pipeline, marketing platform, or a CI step. The exact message your audience would receive is what gets rendered.
03
Request the client previews

POST /ext/v2/client-previews with email_source set to spam-check and the test id as source_id, then poll GET /ext/v2/client-previews/{id} on a back-off while devices are pending; URLs appear as each one completes.
04
Filter devices when you need to (optional)

Pull the catalog from GET /ext/v2/client-preview-devices and pass devices in the POST body to render a subset. The same test also serves /screenshots and /heatmap if you want the visual extras.

Frequently asked questions about the API.

Integration, device filtering, MCP access for AI agents, and how the preview endpoints behave.

How do I get API access?

API access is included with the Custom plan, which you buy online: pick the monthly volume of each test on the pricing page, from a $5 minimum, and the rates drop as you grow. You can build it into your own product and resell it under your own brand. For anything else, open a support ticket.

How does the email preview flow work?

Previews are requested for a spam-check. POST /ext/v2/spam-check returns an inbox_address; you send the real email there; then POST /ext/v2/client-previews with email_source set to spam-check and the test id as source_id starts the renders, and GET /ext/v2/client-previews/{id} returns one entry per device with per-device status and image URLs. Devices complete independently, so poll until the set you need is completed. To preview HTML you have not sent, set email_source to raw-data and pass a subject and body instead.

Can I render only specific clients?

Yes. Pass devices in the POST /ext/v2/client-previews body with keys from GET /ext/v2/client-preview-devices to render a subset, for example only iOS Mail or only the Outlook family. A preview request spends one device preview from your allowance whatever the number of devices, so scoping changes what comes back, not what it costs.

Are the previews real clients or simulations?

Real clients. Each render is your email opened in an actual copy of the client and device and captured as a screenshot, in both light and dark mode. That is the difference between an email rendering API built on live clients and the CSS-transform simulations most free preview tools return.

Can I use it for rendering QA in CI?

That is the main use case. Run a template change through the flow in a CI step, pull the renders for your critical clients, and attach them as build artifacts or diff them against the previous run. The same test returns the spam score, so one job covers rendering and deliverability together.

Can AI agents run email previews?

Yes. The preview endpoints are exposed as tools on the Unspam MCP server: create_client_preview, list_client_previews and list_client_preview_devices, next to the spam-check and inbox-placement tools. Connect Claude, Cursor, or ChatGPT over OAuth and ask for renders in plain language; no keys to paste.

How is this different from the screenshots endpoint?

/spam-check/{id}/screenshots returns three viewport renders (desktop, tablet, mobile) of the message. POST /client-previews renders the email inside 50+ real client applications, each in light and dark mode, so it catches client-specific breakage like the Outlook Word engine or a dark-mode logo inversion.

What are the rate limits?

The public limit is 100 requests per minute per IP or per authenticated account. Preview polling fits comfortably inside it with a normal back-off. If you need a higher limit, open a support ticket with your expected throughput.

Can I build this into my own product and resell it?

Yes, on the Custom plan. Every preview comes back as JSON with an image URL for each client and device, so you can show the renders in your own interface and resell them to your clients under your own brand.

Ready to render emails from your own stack?

API access is included with the Custom plan, bought online from a $5 monthly minimum. Build it into your own product and resell it under your own brand.

See pricing