E-Mail-Vorschau-API.

Rendere deine echte E-Mail in über 50 echten E-Mail-Clients und auf echten Geräten, per REST: Spam-Test anlegen, Nachricht senden, dann pixelgenaue Client-Vorschauen als JSON auslesen, jede aus einem echten Client im hellen und im dunklen Modus aufgenommen. Dieselben Renderings gibt es als MCP-Tools, damit KI-Agenten einen Rendering-Test in normaler Sprache starten können.

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
  ]
}

Zwei Vorschau-Endpoints. Die ganze Suite mit einem Key.

Die E-Mail-Vorschau-API teilt sich Token, Rate Limits und Abrechnung mit der Spam-Check- und der Inbox-Placement-API. Rendering hängt sich also an die Integration, die du ohnehin schon betreibst.

Client-Vorschauen

GET /spam-check/{id}/client-previewsRendering deiner E-Mail in über 50 echten Clients und auf echten Geräten, hell und dunkel, als PNGs vom CDN.

Gerätekatalog

GET /client-preview-devicesJeder renderbare Client mit Key und Kategorie, als Basis für den devices-Filter.

Spam-Tests

POST /spam-checkDer Test, der die Vorschauen trägt: Score, Absender-Forensik und die Aufschlüsselung pro Check im selben Ergebnis.

MCP-Tools

get_spam_check_client_previewsDie Vorschau-Endpoints als MCP-Tools für Claude, Cursor, ChatGPT und jeden Remote-MCP-Client.

Warum Teams Vorschauen in ihre Pipeline einbauen.

Aufnahmen aus echten Clients, keine Simulationen.

Jede Vorschau ist deine E-Mail, geöffnet in einer echten Installation des Clients auf dem echten Gerät und dann als Screenshot aufgenommen. Keine CSS-Transformationen, keine Browser-Emulation: Das PNG, das du bekommst, ist genau das, was ein Abonnent in diesem Client sieht.

Hell und dunkel in jedem Client.

Jeder der über 50 Clients rendert in beiden Modi. Ein Aufruf liefert also über 100 Bilder, und das invertierte Logo oder der unlesbare Text im Dark Mode fällt in deiner Pipeline auf, nicht in der Produktion.

Renderings mit dem Parameter <code>devices</code> eingrenzen.

Übergib devices mit Keys aus dem Katalog, um nur die Clients zu rendern, die dich interessieren (nur iOS Mail, nur die Outlook-Versionen), oder lass den Parameter weg für den kompletten Satz. Neu angeforderte Geräte kommen als pending zurück; frag sie ab, bis jedes auf completed steht.

MCP-Tools für KI-Agenten.

Die Vorschau-Endpoints gibt es als MCP-Tools (get_spam_check_client_previews, list_client_preview_devices) auf dem Unspam MCP-Server. Claude, Cursor oder jeder andere MCP-Client holt sich damit echte Client-Renderings mitten im Gespräch.

Was die Vorschau-Endpoints zurückgeben.

Screenshots aus echten Clients als JSON: ein Eintrag pro Gerät, jeder aus einem echten Client im hellen und im dunklen Modus aufgenommen.

01

Pixelgenaue Vorschauen als Sub-Ressource des Spam-Tests.

GET /spam-check/{id}/client-previews gibt einen status auf oberster Ebene zurück sowie ein Array previews[] mit einem Eintrag pro Gerät: device_key, device_name, einen eigenen status pro Gerät und CDN-URLs für das original- und das thumbnail-Rendering.

original und thumbnail bleiben null, bis das jeweilige Gerät auf completed springt. Eine einfache Polling-Schleife holt so den ganzen Satz ab. Die meisten Geräte sind nach etwa einer Minute da.

gmail · hell
outlook · dunkel
iphone
02

Ein Gerätekatalog, gegen den du filtern kannst.

GET /client-preview-devices listet jeden renderbaren Client mit device_key, Anzeigename und Kategorie auf (DESKTOP, MOBILE, WEB). Leg ihn im Cache ab, zeig ihn in deiner eigenen UI oder bau daraus den devices-Filter für den Render-Aufruf.

Filtern zahlt sich beim Limit aus: Wenn du drei Outlook-Versionen statt des kompletten Satzes renderst, verbrauchst du deine Geräte-Vorschauen gezielt. Genau das willst du in einem CI-Job, der bei jeder Template-Änderung läuft.

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

Dieselben Vorschauen, per MCP von KI-Agenten aufrufbar.

Verbinde den Unspam MCP-Server per OAuth, und dein Assistent bekommt die Vorschau-Tools direkt neben Spam-Tests und Inbox Placement. Bitte ihn, die Kampagne zu rendern und alles zu melden, was im Dark Mode von Outlook kaputt ist: Die Aufrufe verkettet er selbst.

Kein anderer Anbieter für E-Mail-Vorschauen gibt KI-Agenten heute Zugriff auf Renderings aus echten Clients. Mit MCP übernehmen deine Agenten-Workflows die Rendering-QA, ohne dass jemand ein Dashboard öffnet.

  • Rendere diese Kampagne get_spam_check_client_previews
  • Welche Clients kannst du rendern? list_client_preview_devices
  • Führe den kompletten Check aus start_spam_check

So funktioniert die E-Mail-Vorschau-API in vier Schritten.

Vorschauen laufen über den Spam-Test: Test anlegen, deine E-Mail an die Adresse schicken, die wir zurückgeben, dann die Renderings pro Gerät auslesen.

  1. 01

    Spam-Test anlegen

    POST /ext/v2/spam-check mit deinem Bearer-Token. Die 201-Response gibt eine Test-id und eine eindeutige inbox_address zurück.

  2. 02

    E-Mail an die Test-Adresse schicken

    Aus deiner transaktionalen Pipeline, deiner Marketing-Plattform oder einem CI-Schritt. Gerendert wird genau die Nachricht, die auch deine Empfänger bekommen würden.

  3. 03

    Client-Vorschauen auslesen

    GET /ext/v2/spam-check/{id}/client-previews gibt die Renderings pro Gerät zurück. Frag mit Back-off ab, solange Geräte auf pending stehen; die URLs erscheinen, sobald ein Gerät fertig ist.

  4. 04

    Geräte filtern, wenn du es brauchst (optional)

    Hol dir den Katalog über GET /ext/v2/client-preview-devices und übergib devices, um nur eine Teilmenge zu rendern. Derselbe Test liefert auch /screenshots und /heatmap, wenn du die visuellen Extras willst.

Häufige Fragen zur API.

Integration, Gerätefilter, MCP-Zugang für KI-Agenten und wie sich die Vorschau-Endpoints verhalten.

Wie bekomme ich API-Zugang?
API-Zugang gibt es in unserem White-Label-Plan, der komplett individuell ist: Die Limits für Spam-Tests, Inbox-Placement-Tests und Geräte-Vorschauen werden auf dein Konto zugeschnitten. Sprich mit dem Vertrieb und nenne dein erwartetes Volumen, dann schneiden wir es passend zu.
Wie läuft die E-Mail-Vorschau ab?
Vorschauen sind eine Sub-Ressource des Spam-Tests. POST /ext/v2/spam-check gibt eine inbox_address zurück, du schickst die echte E-Mail dorthin, und GET /ext/v2/spam-check/{id}/client-previews liefert dann einen Eintrag pro Gerät mit eigenem status und Bild-URLs. Geräte werden unabhängig voneinander fertig, frag also ab, bis der Satz, den du brauchst, auf completed steht.
Kann ich nur bestimmte Clients rendern?
Ja. Übergib den Query-Parameter devices mit Keys aus GET /ext/v2/client-preview-devices, um nur eine Teilmenge zu rendern, zum Beispiel nur iOS Mail oder nur die Outlook-Familie. Wenn du das Rendering eingrenzt, grenzt du damit auch ein, was es von deinem Limit für Geräte-Vorschauen verbraucht.
Sind die Vorschauen echte Clients oder Simulationen?
Echte Clients. Jedes Rendering ist deine E-Mail, geöffnet in einer echten Installation des Clients auf dem echten Gerät und als Screenshot aufgenommen, im hellen wie im dunklen Modus. Genau das unterscheidet eine E-Mail-Rendering-API auf Basis echter Clients von den CSS-Simulationen, die die meisten kostenlosen Vorschau-Tools liefern.
Kann ich damit Rendering-QA in der CI machen?
Das ist der Hauptanwendungsfall. Schick eine Template-Änderung in einem CI-Schritt durch den Ablauf, hol dir die Renderings deiner kritischen Clients und häng sie als Build-Artefakte an oder vergleiche sie mit dem vorherigen Lauf. Derselbe Test liefert den Spam-Score, ein Job deckt also Rendering und Zustellbarkeit zusammen ab.
Können KI-Agenten E-Mail-Vorschauen erzeugen?
Ja. Die Vorschau-Endpoints stehen als Tools auf dem Unspam MCP-Server bereit: get_spam_check_client_previews und list_client_preview_devices, direkt neben den Tools für Spam-Test und Inbox Placement. Verbinde Claude, Cursor oder ChatGPT per OAuth und frag in normaler Sprache nach Renderings, ganz ohne Keys zum Einfügen.
Was ist der Unterschied zum Screenshots-Endpoint?
/spam-check/{id}/screenshots liefert drei Viewport-Renderings der Nachricht (Desktop, Tablet, Mobil). /spam-check/{id}/client-previews rendert die E-Mail in über 50 echten Client-Anwendungen, jeweils im hellen und im dunklen Modus, und fängt so Client-spezifische Fehler ab, etwa die Word-Engine von Outlook oder ein im Dark Mode invertiertes Logo.
Wie sehen die Rate Limits aus?
Das öffentliche Limit liegt bei 100 Requests pro Minute pro IP oder pro authentifiziertem Konto. Polling für Vorschauen passt mit normalem Back-off bequem hinein. Wenn du mehr Burst-Kapazität brauchst, öffne den Chat und nenne deinen erwarteten Durchsatz.

Bereit, E-Mails aus deinem eigenen Stack zu rendern?

API-Zugang ist im White-Label-Plan enthalten. Preise auf der öffentlichen Seite, individuelle Limits im Chat.

Preise ansehen