DocsBald verfügbar

Schnellstart

Die erste E-Mail mit einem Aufruf versenden und nachsehen, was mit ihr geschehen ist.

Sie brauchen ein aktives Konto, eine verifizierte Absenderdomain und einen API-Key aus dem Dashboard. Jeder Aufruf geht an https://api.letr.dev, mit dem Key als Bearer-Token.

Noch keine Domain verifiziert? Senden Sie mit einem API-Key, der versenden darf (sending_access oder full_access), von [email protected] an [email protected]: Die E-Mail verlässt letr.dev nie, ihre Ereignisse sind echt, und sie zählt nicht zum Verbrauch. Testempfänger nennt alle Ergebnisse.

E-Mail versenden

Der kleinste gültige Aufruf nennt Absender, Empfänger, Betreff und Inhalt:

curl https://api.letr.dev/v1/emails \
  -H "Authorization: Bearer $LETR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "Acme <[email protected]>",
    "to": "[email protected]",
    "subject": "Hello from Acme",
    "text": "It works."
  }'

letr.dev speichert die E-Mail und antwortet mit 202 Accepted und ihrer ID. Die Zustellung läuft im Hintergrund.

{ "id": "em_gk3lx0aqw2rz9vb7nc1ep4ty", "status": "queued" }
E-Mail versendenIhre App sendet die E-Mail mit einem Idempotency-Key und erhält 202 mit ihrer ID. Unabhängig voneinander sendet letr.dev das Ereignis email.sent signiert an Ihren Webhook-Endpunkt und übergibt die E-Mail dem Mailserver des Empfängers; sobald dieser Server sie annimmt, sendet letr.dev email.delivered. Ihre App prüft jede Signatur und antwortet mit 2xx.Mailserver des Empfängersletr.devIhre Apppar[Ereignis][Zustellung]Signatur prüfenPOST /v1/emails, Idempotency-Key202 { id, status: queued }Webhook email.sent, signiert2xxSMTP, mit DKIM signiert250 angenommenWebhook email.delivered, signiert2xx

Die Absenderadresse muss eine verifizierte Domain Ihres Kontos verwenden, sonst lautet die Antwort 422 domain_not_verified. Unter Fehler stehen alle Codes.

Status prüfen

curl https://api.letr.dev/v1/emails/em_gk3lx0aqw2rz9vb7nc1ep4ty \
  -H "Authorization: Bearer $LETR_API_KEY"

Die Antwort enthält den aktuellen status (scheduled, canceled, queued, sent, delivered, deferred, bounced, complained oder failed) und jedes Ereignis mit Typ, Empfänger, SMTP-Detail und Zeit. Statt nachzufragen, lassen Sie sich informieren: Ein Webhook erhält jedes Ereignis, sobald es eintritt.

Status einer E-MailEine neue E-Mail ist queued, oder scheduled, wenn sie scheduledAt hat. Eine geplante E-Mail wird queued, wenn ihr Zeitpunkt kommt, vorher canceled, oder failed, wenn ihr Zeitpunkt kommt, während das Konto pausiert oder deaktiviert ist. Ab queued geht eine E-Mail weiter zu sent, deferred oder einem der Endstatus delivered, bounced und failed; eine späte Bounce-Meldung macht aus delivered bounced, und jeder Endstatus kann zu complained werden. In jedem Status wird eine E-Mail canceled, wenn eine Adresse gelöscht wird, während noch ein Empfänger wartet.queued oder späterdelivered, bounced oder failedspäte Bounce-Meldungmit scheduledAtstorniert, Key widerrufen, Keyerneuert(fällig nach seiner Frist),Adresse gelöschtfällig, während das Kontopausiert oder deaktiviert istPOST /v1/emailsscheduledAt erreichtAdresse gelöscht, währendein Empfänger noch wartetdeliveredbouncedfailedqueuedsentdeferredcomplainedscheduledcanceled

Jeder Pfeil ohne Beschriftung ist das gleichnamige Ereignis, zum Beispiel email.sent. Der Status kehrt nie zu einer früheren Stufe zurück, kann aber eine überspringen. Ein Endstatus (delivered, bounced oder failed) kann noch zu einem anderen Endstatus oder zu complained wechseln: bei einem Empfänger durch eine späte Bounce-Meldung, bei mehreren Empfängern durch das Ereignis, das letr.dev zuletzt verarbeitet hat.

Weiter