Changelog: E-Mail-API

Die Schaltfläche Retry bei einer zurückgehaltenen E-Mail funktioniert jetzt, und E-Mail erneut senden akzeptiert E-Mails mit dem Status held. Beheben Sie zuerst den Grund für das Zurückhalten, zum Beispiel einen hohen Spam-Score oder fehlende Credits, und senden Sie die E-Mail dann erneut.

Erneutes Senden erzeugt eine neue E-Mail mit neuer ID und kostet Credits wie jede andere Sendung. E-Mails, die älter als 30 Tage sind oder deren Inhalt durch die Datenaufbewahrung entfernt wurde, lassen sich nicht erneut senden. Siehe Erneut senden und weiterleiten.

Emailit vergleicht die Adressen in Reply-To und From und ignoriert dabei Anzeigenamen sowie Groß- und Kleinschreibung. Sind sie gleich, entfernt Emailit Reply-To, bevor die Nachricht signiert wird. Antworten erreichen weiterhin die Adresse in From.

Unterscheiden sich die Adressen, bleibt Reply-To unverändert. Siehe E-Mail-Header.

• API und SMTP gleichen die Domain in From ohne Beachtung der Groß-/Kleinschreibung ab, sodass ada@Acme.com über die verifizierte Domain acme.com sendet.
• Wenn Sie die Tracking- oder Inbound-Subdomain einer Domain in der Weboberfläche oder mit tracking_key und inbound_key in Domain aktualisieren ändern, wird der neue Wert jetzt gespeichert. Legen Sie den DNS-Eintrag für den neuen Namen an und verifizieren Sie ihn.

• API-Schlüssel, die erstellt wurden, bevor Schlüssel das Präfix secret_ hatten, werden unter /v2 wieder akzeptiert.
• E-Mail abrufen gibt das vollständige E-Mail-Objekt zurück, einschließlich object, from und to.
• Antworten zu Domains geben track_loads und track_clicks wie dokumentiert als 0 oder 1 zurück.

Eine Sendeanfrage mit aktiviertem tracking schlug bisher mit 422 fehl, wenn die Versanddomain keinen verifizierten Tracking-CNAME hatte. Jetzt nimmt Emailit die E-Mail an und sendet sie, ohne Links umzuschreiben oder das Tracking-Pixel einzufügen.

Um Öffnungen und Klicks zu tracken, legen Sie den Tracking-CNAME-Eintrag für Ihre Domain an und verifizieren ihn. Siehe Eigene Tracking-Domain.

Vorübergehende Fehler wurden beim Zustellversuch erfasst, aber die E-Mail behielt ihren vorherigen Status. Jetzt wechselt die E-Mail selbst zu attempted, während Emailit es erneut versucht, sodass die E-Mail-Liste und die API zeigen, welche E-Mails sich verzögern.

Spätere Status wie delivered und endgültige Status werden nicht überschrieben. Siehe E-Mail-Status.

• Compose auf der Seite Emails oder unter Quick Actions auf der Seite Dashboard sendet eine einzelne E-Mail von einer verifizierten Domain, zum Beispiel um Ihre Einrichtung zu testen. Unter Advanced können Sie die Sendung einem API-Schlüssel zuordnen. Compose erlaubt 3 E-Mails pro Minute und 10 pro Stunde je Workspace. Siehe E-Mail verfassen.
• Cancel delivery nimmt eine angenommene, geplante oder vorübergehend fehlgeschlagene E-Mail aus der Warteschlange. Die Stornierung erfolgt nach bestem Bemühen: Eine E-Mail, die gerade an den Server des Empfängers übergeben wird, kann trotzdem zugestellt werden. Siehe E-Mail stornieren.

Wählen Sie Forward auf der Detailseite einer E-Mail oder rufen Sie E-Mail weiterleiten mit einer Adresse in to auf. Standardmäßig erhält der Empfänger eine einfache Kopie. Aktivieren Sie die weitergeleiteten Header und fügen Sie einen Kommentar hinzu, wenn Sie Kontext geben möchten.

Eine Weiterleitung ist eine neue E-Mail: Sie kostet Credits und zählt zu Ihren Versandlimits. Sie können 3 E-Mails pro Stunde je Workspace weiterleiten. Siehe Erneut senden und weiterleiten.

Die Sandbox-Regel gilt jetzt für API, SMTP, Compose, erneutes Senden, Automatisierungen und Kampagnen. Das Senden an andere Empfänger gibt per API 403 mit dem Code unverified_workspace_recipient und per SMTP 550 zurück, und Kampagnenversände werden blockiert. Workspaces mit Produktionszugang sind nicht betroffen.

Um die Einschränkung aufzuheben, verifizieren Sie eine Domain und beantragen Sie Produktionszugang.

Reine Sende-Schlüssel konnten bisher E-Mails auflisten und abrufen und einige andere lesende Endpunkte aufrufen. Jetzt sind sie auf E-Mail senden und die Aktionen für eine bestehende E-Mail beschränkt: verschieben, stornieren, erneut senden und weiterleiten. Andere Endpunkte lehnen Sende-Schlüssel ab.

Wenn Ihre Integration auch E-Mails, Domains oder andere Ressourcen liest, verwenden Sie für diese Aufrufe einen Schlüssel mit Vollzugriff. Siehe API-Schlüssel.

• E-Mails auflisten: GET /v2/emails
• Roh-MIME abrufen: GET /v2/emails/:id/raw
• Inhalt abrufen: GET /v2/emails/:id/body
• Metadaten abrufen: GET /v2/emails/:id/meta
• Anhänge auflisten: GET /v2/emails/:id/attachments

Diese Endpunkte erfordern einen Schlüssel mit Vollzugriff. Inhalte bleiben verfügbar, bis die Datenaufbewahrung Ihres Tarifs sie entfernt.

Bestehende E-Mails und Zustellungen wurden auf die neuen Namen migriert. Events und Webhook-Anfragen, die vor der Änderung erstellt wurden, behalten die Werte, mit denen sie gesendet wurden. Die aktuelle Liste finden Sie unter E-Mail-Status.

Erstellen Sie Vorlagen im HTML-Editor, im Rich-Text-Editor oder im Drag-and-drop-Editor Dragit. Vorlagen mit demselben Alias sind Versionen einer Vorlage, und beim Senden per Alias wird nur die veröffentlichte Version verwendet.

Verwalten Sie Vorlagen mit der Vorlagen-API und senden Sie eine Vorlage, indem Sie template und variables an E-Mail senden übergeben. Siehe Vorlagen.

Retry dupliziert die ursprüngliche E-Mail, gibt der Kopie eine neue ID und sendet sie über die normale Pipeline. Sie wird wie jede neue E-Mail abgerechnet. Um aus Ihrem Code erneut zu senden, rufen Sie E-Mail erneut senden auf.

• E-Mail senden: Jeder Empfänger erhält eine eigene E-Mail-ID. Planen Sie den Versand mit einem Datum im Format ISO 8601, einem Unix-Zeitstempel oder natürlicher Sprache wie „tomorrow at 9am“ und verhindern Sie Duplikate mit dem Header Idempotency-Key.
• E-Mail abrufen: Status, Header, Inhalt, Tracking-Einstellungen und Metadaten.
• Geplante E-Mail aktualisieren: Ändern Sie den Sendezeitpunkt bis 3 Minuten vor dem Versand.
• E-Mail stornieren: Stoppen Sie eine geplante E-Mail oder eine E-Mail in der Warteschlange.

Jede Antwort auf eine Sendung enthält die Header ratelimit-*. Siehe Rate Limits.

Anfragen über dem Limit werden abgelehnt statt in die Warteschlange gestellt. Konfigurieren Sie Ihren Client daher so, dass er höchstens 2 E-Mails pro Sekunde sendet oder abgelehnte Sendungen wiederholt. Die Änderung wurde schrittweise für die Workspaces eingeführt.

Siehe Rate Limits.