Route · Email API

API e-mail

Invia OTP, reimpostazioni password, avvisi account, fatture e messaggi del ciclo di vita da un'unica API. Sendarix è progettato per un comportamento prevedibile su scala, non per integrazioni fragili.

cURL Node SMTP
# Invia un’email critica tramite routing policy
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"
});
# SMTP drop-in — mantieni l’integrazione e ottieni un control plane
host:     smtp.sendarix.com
port:     587  (STARTTLS)
username: "your_sending_key"
header:   X-Sendarix-Policy: transactional-critical

Un contratto stabile

Un'API pratica per i team che rilasciano velocemente

Autentica le richieste, invia i messaggi e traccia i risultati in una pipeline coerente. Ogni invio può essere osservato tramite log, eventi e webhook.

architettura · stack delivery nativo
La tua applicazione CONTROL PLANE SENDARIX Routing policy + failover İzolasyon tenant + pool İzleme events + health Kurtarma reroute EU relay US relay Dedicated IP’ler Tenant havuzları Inbox sağlayıcıları · Gmail · Microsoft 365 · Yahoo

UI prodotto rappresentativa — dati illustrativi, non metriche live dei clienti.

Cosa ottieni

L'API è volutamente semplice: creare e inviare messaggi, ispezionare i risultati e automatizzare le reazioni. Aiuta i team prodotto a andare più veloce senza compromettere l'affidabilità.

Integrazione REST rapida

Modelli chiari di richiesta/risposta e comportamento prevedibile per servizi backend moderni e strumenti interni.

Tracciamento del ciclo di vita del messaggio

Traccia stati accettato, consegnato, rimbalzato e segnalato come spam così il prodotto può reagire in tempo reale.

Visibilità operativa

Log ricercabili e flussi di eventi riducono i tempi di troubleshooting quando gli utenti segnalano problemi di consegna.

Scala senza riscrivere tutto

Da carichi iniziali a flussi ad alto volume, mantieni un unico contratto API mentre cresce il volume.

Iniezione dati nei template

Passa variabili dinamiche in modo ordinato così i template transazionali restano coerenti tra i prodotti.

Pattern di invio idempotenti

Evita invii duplicati negli scenari di retry con strategie deterministiche di gestione delle richieste.

Flusso API tipico

Un modello semplice che il team può implementare una volta e riusare in tutti gli scenari transazionali.

1. Invia la richiesta

Il servizio invia un payload con destinatario, dati template e metadati.

2. Valida e metti in coda

Controlli di input, logica di soppressione e accodamento avvengono prima della fase di consegna.

3. Consegna

I messaggi vengono instradati a provider di destinazione con comportamento di invio controllato.

4. Consuma gli eventi

Usa webhook e log per aggiornare lo stato del prodotto e attivare automazioni a valle.

Domande frequenti

Possiamo usare API e SMTP insieme?

Sì. Molti team usano l'API per i flussi applicativi e SMTP per i sistemi legacy durante la migrazione.

Abbiamo dati evento per ogni messaggio?

Sì. Eventi di consegna, rimbalzo e reclamo sono disponibili per flussi operativi e di prodotto.

È adatto al traffico ad alto volume?

Sì. Lo stesso modello API copre fasi a basso volume e invio sostenuto ad alto volume.

Servono SPF, DKIM e DMARC per l'invio via API?

Autenticare il dominio di invio è fortemente consigliato. Migliora come i provider di posta valutano la posta ed è un'aspettativa di base in produzione.

Come funzionano chiavi API e permessi?

Puoi emettere chiavi per ambiente o servizio e limitare cosa può fare ciascuna chiave, così staging, CI e produzione restano isolati.

Cosa succede se la nostra integrazione invia richieste non valide o duplicate?

L'API restituisce errori di validazione chiari. Per i retry usa identificatori stabili nel livello applicativo per non duplicare la stessa e-mail verso l'utente.

Possiamo correlare le chiamate API con la consegna a valle?

Sì. Identificatori di messaggio e timeline di eventi collegano un invio API a esiti accettato, consegnato, rimbalzato o differito.

L'API e-mail è adatta a reimpostazioni password e codici OTP?

Sì. Sono casi transazionali classici: basse latenze attese, alta visibilità e legame stretto con auth o rischio.

Dobbiamo usare solo HTTPS per il traffico API?

Sì. TLS protegge credenziali e metadati in transito. Tratta gli endpoint API come qualsiasi superficie di produzione con segreti.

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).

Protege email crítico en cada tenant.

Mueve tu stream más crítico a Sendarix esta semana. Deja todo lo demás exactamente donde está.