Email Preview API.

Render your real email across 50+ real email clients and devices via REST: create a spam-check, send the message, then read back pixel-accurate client previews 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.

GET /ext/v2/spam-check/{id}/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 https://api.unspam.email/ext/v2/spam-check/2Bl8rzTFN6VV/client-previews \
  -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.png"
    }
    // one entry per device, 50+ in total
  ]
}

Two preview endpoints. 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

GET /spam-check/{id}/client-previewsYour email rendered in 50+ real clients and devices, light and dark, as CDN-hosted PNGs.

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

get_spam_check_client_previewsThe 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 PNG 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 (get_spam_check_client_previews, 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 as a spam-check sub-resource.

GET /spam-check/{id}/client-previews returns a top-level status and a previews[] array with one entry per device: device_key, device_name, per-device status, and CDN 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 matters for quota: rendering three Outlook versions instead of the full set spends your device previews deliberately, which is exactly what you want in a CI job that runs on every template change.

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.

No other email preview service exposes real client renders to AI agents today: MCP support means your agent workflows can do rendering QA without a human opening a dashboard.

Render this campaign get_spam_check_client_previews
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, 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
Read the client previews

GET /ext/v2/spam-check/{id}/client-previews returns the per-device renders. Poll 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 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 ships under our White Label plan, which is fully custom: limits for spam-checks, inbox-placement tests, and device previews are sized to your account. Talk to sales with your expected volume and we will scope a fit.

How does the email preview flow work? +

Previews are a sub-resource of a spam-check. POST /ext/v2/spam-check returns an inbox_address; you send the real email there; then GET /ext/v2/spam-check/{id}/client-previews returns one entry per device with per-device status and image URLs. Devices complete independently, so poll until the set you need is completed.

Can I render only specific clients? +

Yes. Pass the devices query parameter with keys from GET /ext/v2/client-preview-devices to render a subset, for example only iOS Mail or only the Outlook family. Scoping the render also scopes what it costs against your device-preview quota.

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: get_spam_check_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. /spam-check/{id}/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 higher burst capacity, open chat with your expected throughput.

Ready to render emails from your own stack?

API access is included with the White Label plan. Pricing on the public page, custom limits over chat.

See pricing