Interaktive transaktionale E-Mails über die Send API

Die meisten Versender transaktionaler E-Mails rendern nur reines HTML. POST /api/v1/send im Vorlagenmodus rendert stattdessen eines Ihrer eigenen Studio-Projekte — komplett mit Fallback-Engine und interaktiven Blöcken —, wobei mergeData für die Zeile dynamischer Werte einsteht. So kann eine Quittungs- oder Bestätigungs-E-Mail, die Ihr Backend auslöst, einen Bewertungs-Block oder einen Produkt-Upsell tragen, genau wie ein Marketing-Versand.

Betreff

Your order receipt

Die meisten Versender transaktionaler E-Mails rendern nur reines HTML. POST /api/v1/send im Vorlagenmodus rendert stattdessen eines Ihrer eigenen Studio-Projekte, komplett mit Fallback-Engine und interaktiven Blöcken. Eine Quittung oder Bestätigung, die Ihr Backend auslöst, kann einen Bewertungs-Block oder einen Produkt-Upsell tragen, genau wie ein Marketing-Versand.

Eine Quittung ist eine der E-Mails mit der höchsten Öffnungsrate, die ein Unternehmen versendet — und fast immer die schlichteste, weil sie meist von der transaktionalen Bibliothek erzeugt wird, die am einfachsten anzubinden war, nicht von etwas mit einem angeschlossenen Designsystem.

Gestalten Sie sie einmal, lösen Sie sie von Ihrem Backend aus

Bauen Sie die Quittung oder Bestätigung als normales Studio-Projekt, mit welchen Blöcken auch immer sinnvoll sind — eine Bewertung für CSAT nach dem Kauf, ein Zubehör-Produkt-Upsell. Ihr Backend ruft dann die Send API im Vorlagenmodus auf, mit der Projekt-ID und einem mergeData-Objekt, das für die dynamischen Werte dieser bestimmten Bestellung einsteht.

Kennzeichnen Sie sie korrekt als transaktional

Wenn Sie type auf "transactional" setzen, umgeht das die Abmeldungs-Sperrung — eine Quittung muss weiterhin jemanden erreichen, der sich vom Marketing abgemeldet hat —, aber nie die Bounce-Sperrung, da eine tatsächlich ungültige Adresse unabhängig vom E-Mail-Typ nicht weiter beliefert werden sollte.

Sie ist authentifiziert wie jede andere API-Integration

Ein pro Inhaber benannter API-Schlüssel, Bearer-authentifiziert, wird im Bereich Entwickler des Dashboards geprägt und widerrufen. Ein Idempotency-Key-Header verhindert, dass eine wiederholte Anfrage die Quittung zweimal versendet.

Was nicht übernommen wird

Der Freiform-Modus (kein projectId, nur rohes html/text) überspringt die Rendering-Pipeline vollständig — keine Merge-Tags, keine Fallback-Engine, unverändert versendet wie angegeben. Das ist die richtige Wahl für etwas wie einen einmaligen OTP-Code; der Vorlagenmodus lohnt sich, sobald die E-Mail selbst von einem interaktiven Block profitiert.

Erste Schritte

Bauen Sie die transaktionale Vorlage als Studio-Projekt mit den gewünschten interaktiven Blöcken, prägen Sie einen API-Schlüssel unter Entwickler, und rufen Sie POST /api/v1/send im Vorlagenmodus mit Ihrem mergeData und type: "transactional" auf.

Ein typischer Ablauf zum Erstellen und Versenden

  1. 1

    Bauen Sie die transaktionale Vorlage als Studio-Projekt

    Gestalten Sie die Quittung oder Bestätigung einmal im Studio, mit welchen interaktiven Blöcken auch immer sinnvoll sind — einer Bewertung, einem Zubehör-Produkt, einer Status-Schaltfläche.

  2. 2

    Prägen Sie einen API-Schlüssel

    Erstellen Sie im Dashboard unter Entwickler einen benannten API-Schlüssel — er authentifiziert jeden Send-API-Aufruf als Bearer-Token.

  3. 3

    Rufen Sie die Send API im Vorlagenmodus auf

    Ihr Backend sendet einen POST an /api/v1/send mit der Projekt-ID und einem mergeData-Objekt, das für die dynamischen Werte dieser bestimmten Bestellung oder dieses Ereignisses einsteht.

  4. 4

    Kennzeichnen Sie sie als transaktional

    Setzen Sie type auf „transactional“, damit der Versand die Abmeldungs-Sperrung umgeht (die Bounce-Sperrung gilt weiterhin) — die richtige Semantik für eine Quittung, die der Empfänger unabhängig von seinen Marketing-Präferenzen braucht.

Häufig gestellte Fragen

Kann eine über die API versendete transaktionale E-Mail dieselben interaktiven Blöcke enthalten wie eine reguläre Kampagne?

Ja — der Vorlagenmodus rendert ein bestehendes Studio-Projekt genau so, wie renderEmail() es für jeden anderen Versand tun würde, sodass jeder Block und die vollständige dreistufige Fallback-Engine identisch übernommen werden.

Wie gelangen empfängerspezifische Daten in die Vorlage, wenn es für einen API-Aufruf keine Datenquellen-Zeile gibt?

Das mergeData-Objekt im Request-Body steht für eine Datenquellen-Zeile ein — bis zu 100 flache Schlüssel/Wert-Felder lösen sich für diesen einen Aufruf in die {{field}}-Merge-Tags des Projekts auf.

Was ist der Unterschied zwischen dem Typ „transactional“ und „marketing“ auf demselben Endpunkt?

Das Feld type steuert, welche Sperrliste geprüft wird: transactional umgeht die Abmeldungs-Sperrung (eine Quittung muss jemanden erreichen, der sich vom Marketing abgemeldet hat), aber nie die Bounce-Sperrung; marketing respektiert beide.

Gibt es ein Ratenlimit für die Send API?

Ja — 60 Anfragen pro Minute pro API-Schlüssel, zusätzlich zu derselben monatlichen Volumengrenze pro Inhaber, die jeder Versandweg teilt; ein Idempotency-Key-Header verhindert, dass eine wiederholte Anfrage zweimal sendet.

Kann ich über denselben Endpunkt statt eines Studio-Projekts eine Freiform-HTML-E-Mail versenden?

Ja — wenn Sie projectId weglassen und stattdessen html/text direkt senden, wird der Freiform-Modus verwendet, unverändert versendet ohne Rendering-Pipeline oder Merge-Tags; der Vorlagenmodus (mit projectId) ist es, der die interaktiven Blöcke und die Fallback-Engine trägt.

Bauen Sie das im Studio

Starten Sie mit dem kostenlosen Tarif — jeder interaktive Block und die vollständige Fallback-Engine sind in jedem Tarif enthalten.