Route · Email API
API e-mail
Envoyez OTP, réinitialisations de mot de passe, alertes de compte, factures et messages du cycle de vie depuis une seule API. Sendarix est conçu pour un comportement prévisible à l’échelle, pas pour des intégrations fragiles.
# Envoyer un email critique via une 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 — gardez votre intégration et gagnez un control plane host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
Un contrat stable
Une API pratique pour les équipes qui livrent vite
Authentifiez les requêtes, soumettez les messages et suivez les résultats dans un pipeline cohérent. Chaque envoi peut être observé via journaux, événements et webhooks.
UI produit représentative — données illustratives, pas de métriques client live.
Ce que vous obtenez
L’API est volontairement simple : créer et envoyer des messages, inspecter les résultats et automatiser les réactions. Les équipes produit avancent plus vite sans sacrifier la fiabilité.
Intégration REST rapide
Modèles requête/réponse clairs et comportement prévisible pour les services backend modernes et les outils internes.
Suivi du cycle de vie des messages
Suivez les états accepté, livré, rebond et plainte pour que votre produit réagisse en temps réel.
Visibilité opérationnelle
Journaux consultables et flux d’événements réduisent le temps de diagnostic lorsque les utilisateurs signalent des problèmes de livraison.
Passer à l’échelle sans tout reconstruire
Des charges initiales aux flux à fort volume, conservez un seul contrat d’API quand le volume augmente.
Injection de données dans les modèles
Passez des variables dynamiques proprement pour que les modèles transactionnels restent cohérents entre produits.
Modèles d’envoi idempotents
Évitez les doublons lors des nouvelles tentatives grâce à un traitement déterministe des requêtes.
Flux API typique
Un schéma simple que votre équipe implémente une fois et réutilise pour tous les cas transactionnels.
1. Soumettre la requête
Votre service envoie une charge utile avec destinataire, données de modèle et métadonnées.
2. Valider et mettre en file
Contrôles d’entrée, logique de suppression et mise en file avant la phase de livraison.
3. Livrer
Les messages sont acheminés vers les fournisseurs avec un comportement d’envoi contrôlé.
4. Consommer les événements
Utilisez webhooks et journaux pour mettre à jour l’état produit et déclencher des automatisations en aval.
Questions fréquentes
Peut-on utiliser l’API et SMTP ensemble ?
Oui. Beaucoup d’équipes utilisent l’API pour les flux applicatifs et SMTP pour les systèmes hérités pendant la migration.
Avons-nous des données d’événement pour chaque message ?
Oui. Livraison, rebond et plaintes sont disponibles pour les flux opérationnels et produit.
Convient-il au trafic à fort volume ?
Oui. Le même modèle d’API couvre les phases à faible volume et l’envoi soutenu à fort volume.
Avons-nous besoin de SPF, DKIM et DMARC pour l’envoi via API ?
Authentifier votre domaine d’envoi est fortement recommandé. Cela améliore l’évaluation par les fournisseurs de messagerie et correspond aux attentes en production.
Comment fonctionnent les clés API et les permissions ?
Vous pouvez émettre des clés par environnement ou service et restreindre les actions, afin de séparer recette, CI et production.
Que se passe-t-il si notre intégration envoie des requêtes invalides ou en double ?
L’API renvoie des erreurs de validation explicites. Pour les nouvelles tentatives, utilisez des identifiants stables dans votre application pour ne pas doubler un e-mail utilisateur.
Peut-on corréler les appels API avec la livraison en aval ?
Oui. Identifiants de message et chronologie d’événements relient une soumission API aux résultats accepté, livré, rebond ou différé.
L’API e-mail convient-elle aux réinitialisations de mot de passe et aux codes OTP ?
Oui. Ce sont des cas transactionnels classiques : faible latence attendue, forte visibilité et lien étroit avec l’auth ou la gestion des risques.
Devons-nous utiliser uniquement HTTPS pour le trafic API ?
Oui. TLS protège les identifiants et les métadonnées en transit. Traitez les points de terminaison API comme toute surface de production exposant des secrets.
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).
Produits associés
Protégez l’email critique de chaque tenant.
Déplacez votre stream le plus critique vers Sendarix cette semaine. Laissez tout le reste exactement où il est.
