Route · Email API
E-Mail-API
Versenden Sie OTPs, Passwort-Resets, Kontowarnungen, Rechnungen und Lifecycle-Nachrichten über eine API. Sendarix ist auf vorhersehbares Verhalten im großen Maßstab ausgelegt – nicht auf fragile Integrationen.
# Kritische E-Mail über eine Routing-Policy senden curl -sS -X POST 'https://app.sendarix.com/v1/email/send' \ -H 'Content-Type: application/json' \ -H 'X-API-Key: YOUR_API_KEY' \ -H 'Idempotency-Key: otp_8842' \ -d '{"to":"user@acme.com","template":"password_reset","routing_policy":"transactional-critical"}'
const sendarix = require("sendarix")(process.env.SENDARIX_KEY); await sendarix.email.send({ to: "user@acme.com", template: "password_reset", routingPolicy: "transactional-critical", idempotencyKey: "otp_8842" });
# Drop-in SMTP — Integration behalten, Control Plane gewinnen host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
Ein stabiler Vertrag
Eine pragmatische API für Teams, die schnell liefern
Authentifizieren Sie Anfragen, übermitteln Sie Nachrichten und verfolgen Sie Ergebnisse in einer konsistenten Pipeline. Jeder Versand lässt sich über Logs, Events und Webhooks nachvollziehen.
Repräsentative Produkt-UI — Beispieldaten, keine Live-Kundenmetriken.
Was Sie erhalten
Die API ist bewusst schlank: Nachrichten erstellen und versenden, Ergebnisse prüfen und Reaktionen automatisieren. So bewegen sich Produktteams schneller voran, ohne Zuverlässigkeit zu opfern.
Schnelle REST-Integration
Klare Request-/Response-Muster und vorhersehbares Verhalten für moderne Backend-Services und interne Tools.
Nachrichten-Lebenszyklus-Tracking
Verfolgen Sie akzeptiert, zugestellt, gebounct und beschwert – damit Ihr Produkt in Echtzeit reagieren kann.
Operative Transparenz
Durchsuchbare Logs und Ereignis-Streams verkürzen die Fehlersuche, wenn Nutzer Zustellprobleme melden.
Skalierung ohne Neuaufbau
Von frühen Workloads bis zu hohen Volumina – ein API-Vertrag bleibt bestehen, wenn das Volumen wächst.
Template-Daten-Injektion
Übergeben Sie dynamische Variablen sauber, damit transaktionale Templates über Produkte hinweg konsistent bleiben.
Idempotente Versandmuster
Verhindern Sie Doppelversände bei Retries mit deterministischem Request-Handling.
Typischer API-Ablauf
Ein einfaches Muster, das Ihr Team einmal implementieren und in allen transaktionalen Szenarien wiederverwenden kann.
1. Request senden
Ihr Service sendet eine Nachrichten-Payload mit Empfänger, Template-Daten und Metadaten.
2. Validieren & Queue
Eingabeprüfungen, Suppression-Logik und Queueing erfolgen vor der Zustellphase.
3. Zustellen
Nachrichten werden mit kontrolliertem Versandverhalten an Ziel-Provider geroutet.
4. Events verarbeiten
Nutzen Sie Webhooks und Logs, um Produktstatus zu aktualisieren und nachgelagerte Automatisierungen auszulösen.
Häufig gestellte Fragen
Können wir API und SMTP parallel nutzen?
Ja. Viele Teams nutzen die API für Anwendungs-Workflows und SMTP für Legacy-Systeme während der Migration.
Erhalten wir Ereignisdaten pro Nachricht?
Ja. Zustell-, Bounce- und Complaint-Events stehen für operative und Produkt-Workflows zur Verfügung.
Eignet sich das für hohe Volumina?
Ja. Dasselbe API-Modell gilt von niedrigen Onboarding-Phasen bis zu dauerhaft hohem Versand.
Brauchen wir SPF, DKIM und DMARC für API-Versand?
Die Authentifizierung Ihrer Versand-Domain wird dringend empfohlen. Sie verbessert, wie Mailbox-Provider Ihre Mail bewerten, und ist Baseline-Erwartung für Produktions-Traffic.
Wie funktionieren API-Keys und Berechtigungen?
Sie können Keys für Umgebungen oder Services ausstellen und einschränken, was jeder Key darf – damit Staging, CI und Produktion getrennt bleiben.
Was passiert bei ungültigen oder doppelten Requests?
Die API liefert klare Validierungsfehler für fehlerhafte Payloads. Nutzen Sie bei Retries stabile Identifier in Ihrer App, damit dieselbe nutzerrelevante E-Mail nicht versehentlich doppelt versendet wird.
Können wir API-Calls mit nachgelagerter Zustellung korrelieren?
Ja. Nachrichten-IDs und Ereignis-Timelines verbinden eine konkrete API-Übermittlung mit akzeptiert, zugestellt, gebounct oder verzögert.
Passt die Email API zu Passwort-Resets und OTP-Codes?
Ja. Das sind klassische transaktionale Fälle: niedrige Latenz, hohe Transparenz und enge Kopplung an Auth- oder Risiko-Systeme.
Sollten wir API-Traffic nur über HTTPS führen?
Ja. TLS schützt Credentials und Nachrichten-Metadaten unterwegs. Behandeln Sie API-Endpunkte wie jede andere produktive Oberfläche mit Geheimnissen.
What is the request rate limit on the Email API?
Rate limits vary by plan. Standard plans allow 1,000 requests/minute; enterprise plans support higher throughput. Rate limit headers are included in every response (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset). Exceeding the limit returns 429 Too Many Requests.
How do we handle API failures gracefully in our application?
Implement exponential backoff with jitter for retries. Treat 429 as a signal to slow down, 5xx as transient errors to retry, and 4xx (except 429) as permanent failures that should not retry. Store the message_id from successful submissions to correlate with downstream webhook events.
What is the maximum message size via API?
Messages up to 50MB total payload are accepted. For files larger than 25MB, Sendarix recommends hosting files externally and including a signed download link in the email body rather than attaching directly. Some mail servers reject messages exceeding 25MB.
Can we schedule email delivery for a future time?
Yes. Pass a scheduled_time parameter (ISO 8601 UTC timestamp) in your API request. Messages are queued and delivered at the specified time. Scheduled messages can be cancelled before delivery by calling the message cancel endpoint with the message_id.
How do we handle unsubscribe programmatically via the API?
The API provides /unsubscribes endpoints for managing suppression records. When a user unsubscribes, add them via the API to prevent future sends to that address. This integrates with the email webhooks unsubscribe event for automatic suppression list updates.
What response codes should our retry logic handle?
Handle these specifically: 200 OK (success, no retry), 400 Bad Request (invalid payload, fix before retry), 401 Unauthorized (invalid API key, do not retry), 422 Unprocessable Entity (validation error, fix payload), 429 Too Many Requests (rate limited, retry after X-RateLimit-Reset), 500 Internal Server Error (transient, retry with backoff).
Verwandte Produkte
Schützen Sie kritische E-Mail über jeden Tenant hinweg.
Verschieben Sie diese Woche Ihren kritischsten Stream zu Sendarix. Alles andere bleibt genau dort, wo es ist.
