OTP, şifre sıfırlama, hesap uyarıları, faturalar ve yaşam döngüsü mesajlarını tek bir API üzerinden gönderin. Sendarix, kırılgan entegrasyonlar için değil, ölçekte öngörülebilir davranış için tasarlanmıştır.
İstekleri doğrulayın, mesajları gönderin ve sonuçları tutarlı bir boru hattında takip edin. Her gönderim günlükler, olaylar ve webhooks üzerinden izlenebilir.
API calls flow through structured validation, queue management, and email routing before reaching destination servers. Delivery outcomes are surfaced via email webhooks and tracked in email analytics.
API kasıtlı olarak sade tutulmuştur: mesaj oluşturup gönderin, sonuçları inceleyin ve tepkileri otomatikleştirin. Bu, ürün ekiplerinin güvenilirlikten ödün vermeden daha hızlı ilerlemesine yardımcı olur.
Modern arka uç hizmetleri ve dahili araçlar için net istek/yanıt kalıpları ve öngörülebilir davranış.
Kabul edildi, teslim edildi, geri döndü ve şikayet etti durumlarını takip edin; ürününüz gerçek zamanlı tepki verebilsin.
Aranabilir günlükler ve olay akışları, kullanıcılar teslimat sorunları bildirdiğinde sorun giderme süresini azaltır.
Erken aşama iş yüklerinden yüksek hacimli akışlara kadar hacim büyüdükçe tek bir API sözleşmesini koruyun.
Dinamik değişkenleri düzgün iletin; transactional şablonlar ürünler arasında tutarlı kalsın.
Yeniden deneme senaryolarında deterministik istek işleme stratejileriyle yinelenen gönderimleri önleyin.
A successful API response is the start of the message lifecycle, not the end of it.
The system checks authentication, request shape, sender identity, and required fields before accepting the request.
A successful response means the request has been accepted for processing. It does not necessarily mean the message has already been delivered to the destination server.
After acceptance, the message moves through delivery logic that may include queueing, suppression checks, routing policy, and destination-aware pacing.
As the message progresses, delivery events can be exposed to logs, analytics, and webhook consumers so your application can react in near real time. Monitor progression via email analytics or email webhooks.
A successful API response confirms that the request has been accepted into the processing pipeline. Final delivery still depends on validation, suppression checks, routing policy, provider behavior, and downstream delivery outcomes.
Both approaches can send email, but they solve different integration needs.
Best for modern applications that want structured requests, cleaner metadata, and easier automation around delivery state. See API docs for integration details.
Best for older tools, legacy systems, or environments that already speak SMTP and need compatibility with minimal code changes. See SMTP relay for setup details.
Many teams use an email API for product-driven workflows and SMTP relay for compatibility with older tools, internal systems, or third-party applications that already speak SMTP. Check API docs for implementation, email webhooks for event handling, and email analytics for delivery visibility.
Ekibinizin bir kez uygulayıp tüm transactional senaryolarda yeniden kullanabileceği basit bir kalıp.
Hizmetiniz alıcı, şablon verisi ve meta veriyle bir mesaj yükü gönderir.
Girdi kontrolleri, bastırma mantığı ve kuyruğa alma teslimat aşamasından önce gerçekleşir.
Mesajlar kontrollü gönderim davranışıyla hedef sağlayıcılara yönlendirilir.
Webhooks ve günlükleri kullanarak ürün durumunu güncelleyin ve aşağı akış otomasyonlarını tetikleyin.
A payment confirmation is triggered by a webhook from a payment processor. The application sends via the email API with an idempotency key. If the API call is accidentally retried due to a network timeout, the email routing layer recognizes the duplicate and returns the original queued message ID rather than queuing a second send. Delivery is confirmed via email webhooks.
Note: A successful API response (e.g. 202 Accepted) means the message is queued, not delivered. Track final delivery status with email analytics or webhook events.
Every Sendarix API call uses JSON and returns consistent response shapes. Below are the primary endpoints your integration will call most frequently.
POST to /v1/messages with recipient, subject, and template data. Returns a message_id for correlation with downstream webhook events.
POST /v1/messages
Authorization: Bearer sk_live_...
Content-Type: application/json
{
"recipient": "user@example.com",
"subject": "Your verification code",
"template": "otp-code",
"template_data": {
"code": "847291",
"expires_in": "5 minutes"
},
"headers": {
"X-Idempotency-Key": "uuid-v4-here"
}
}
{
"message_id": "msg_abc123xyz",
"status": "queued",
"recipient": "user@example.com",
"created_at": "2026-04-19T14:30:00Z"
}
Returns a message_id and status: queued. Correlate message_id with email webhooks for delivery status.
GET /v1/messages returns a paginated list of messages with filtering by status, recipient, and date range.
GET /v1/messages?status=delivered&limit=25 Authorization: Bearer sk_live_...
GET /v1/messages/{message_id} returns the current state of a specific message including timestamps, recipient, and delivery outcome.
GET /v1/messages/msg_abc123xyz Authorization: Bearer sk_live_...
DELETE /v1/messages/{message_id} cancels a scheduled message before it is delivered. Returns 404 if already sent.
DELETE /v1/messages/msg_abc123xyz Authorization: Bearer sk_live_...
POST /v1/suppressions adds an address to the suppression list to prevent future sends to that recipient.
POST /v1/suppressions
Authorization: Bearer sk_live_...
{
"recipient": "user@example.com",
"reason": "user_unsubscribed"
}
Understanding what happens between an API call and final delivery helps you design more resilient integrations and debug issues faster.
The API validates: required fields (recipient, from, subject), email address format, API key and permissions, content size limits. Validation errors return 400 or 422 immediately with a field-level error array. No message is queued until validation passes.
Validated messages enter the sending queue with a queued status. A message_id is returned immediately so your application can correlate with downstream events. Queue processing is FIFO within priority tiers.
The routing layer selects the optimal sending path based on recipient domain, IP reputation, and provider performance. This is handled automatically by Sendarix infrastructure.
The message is delivered to the recipient's mail server. Delivery outcomes (delivered, bounced, deferred) are posted to your configured webhook endpoint. Track delivery in the email analytics dashboard.
Each message generates a timeline of events: queued → accepted → delivered/bounced/deferred. You receive webhook events for each state change. Between queued and final state, multiple deferred events may fire as the system retries temporary failures.
Deferred messages (temporary provider rejection, greylisting) are retried automatically at increasing intervals: 30 seconds, 5 minutes, 30 minutes, 2 hours, 5 hours. After 6 attempts, the message is marked as permanently bounced and you receive a bounce event.
A production-grade integration handles API errors gracefully. These patterns prevent duplicate sends, data inconsistency, and user-facing failures.
Map status codes to retry behavior:
200
— Success — no retry needed
400
— Bad request — fix payload before retrying
401
— Unauthorized — check API key, do not retry
422
— Validation failed — fix payload, do not retry
429
— Rate limited — retry after X-RateLimit-Reset
500
— Server error — retry with exponential backoff
503
— Service unavailable — retry with backoff
Pass an idempotency_key (UUID v4 recommended) in the request headers: Idempotency-Key: {uuid}. If the same idempotency_key is submitted twice within 24 hours, the API returns the original response without re-sending. This prevents duplicate sends during retry loops.
Every message response includes a message_id. Match this against the message_id in email webhooks to confirm delivery. Never assume a 200 OK means the email was delivered — a 200 confirms the message was queued.
Use this backoff formula: delay = min(base * 2^attempt + jitter, max_delay). Recommended base: 1 second, max_delay: 60 seconds, jitter: 0-1000ms random. Always cap retries at a maximum of 5 attempts to avoid infinite loops.
After exhausting retries, log permanently failed messages to a dead-letter table keyed on message_id. Inspect these periodically to identify systemic issues (bad address patterns, provider problems, template errors) and fix upstream.
The Sendarix API handles all transactional email flows. These are the most common integration patterns.
Send time-sensitive OTP codes for login, password changes, and identity verification. OTP emails require low latency, high deliverability, and clean templates with no distracting content. Set a short TTL in your application — OTP codes are security-sensitive and should not persist in inboxes.
Password reset links must reach users quickly and reliably. These are high-stakes flows — a missed reset email creates support tickets and churn. Pair with email webhooks to detect bounce events and alert security teams if reset emails are bouncing for active users.
Invoice delivery, payment confirmations, and failed payment alerts drive user engagement with billing systems. Use template data injection to personalize invoice amounts and due dates. For failed payments, trigger retry logic in your system based on the bounce event.
Welcome emails, email verification, account suspension, and deletion notices are all driven by user actions in your system. These flows work best with an idempotency key per user action to prevent duplicate sends when users trigger the same action multiple times.
New login detected, password changed, device authorized, unusual activity alerts — these require immediate delivery to catch security incidents. Route these through your highest-priority sending path. Set up real-time email analytics alerts for spike patterns that may indicate a compromised account.
The Email API works alongside SMTP relay for legacy system migration, transactional email templates for content management, and email analytics for cross-channel performance reporting. Build a complete email stack with the API at the center.
Email API, gerçek zamanlı otomasyon için Email Webhooks ve operasyonel içgörü için Email Analytics ile özellikle iyi çalışır.
Tutarlı e-posta teslimatına bağlı SaaS ürünleri, platform ekipleri, hesap sistemleri, faturalama motorları ve müşteri desteği iş akışları.
Need SMTP configuration for a specific provider? Check our step-by-step guides for Gmail SMTP settings, Outlook SMTP configuration, Office 365 setup, Yahoo SMTP settings, and SendGrid SMTP settings.
What sets Sendarix apart: The Sendarix email API is designed around infrastructure control — routing rules, queue behavior, and delivery policy are exposed through the API, giving engineering teams programmatic access to what most platforms hide behind dashboards.
Evet. Birçok ekip uygulama iş akışları için API, geçiş sırasında eski sistemler için SMTP kullanır.
Evet. Teslimat, geri dönüş ve şikayet olayları operasyonel ve ürün iş akışları için kullanılabilir.
Evet. Aynı API modeli düşük hacimli onboarding aşamalarından sürekli yüksek hacimli gönderime kadar kullanılır.
Gönderim alanınızı doğrulamanız şiddetle önerilir. Posta kutusu sağlayıcılarının postanızı nasıl değerlendirdiğini iyileştirir ve üretim trafiği için temel bir beklentidir.
Farklı ortamlar veya hizmetler için anahtarlar çıkarabilir ve her anahtarın ne yapabileceğini kısıtlayabilirsiniz; böylece staging, CI ve üretim izole kalır.
API kötü yükler için net doğrulama hataları döndürür. Yeniden denemeler için uygulama katmanınızda kararlı tanımlayıcılar kullanın; aynı kullanıcıya yönelik e-postayı yanlışlıkla iki kez göndermeyin.
Evet. Mesaj tanımlayıcıları ve olay zaman çizelgeleri, belirli bir API gönderimini kabul edildi, teslim edildi, geri döndü veya ertelendi sonuçlarına bağlamanıza olanak tanır.
Evet. Bu akışlar klasik transactional kullanım durumlarıdır: düşük gecikme beklentisi, yüksek görünürlük gereksinimi ve kimlik doğrulama veya risk sistemlerinizle sıkı bağlantı.
Evet. TLS, aktarımda kimlik bilgilerini ve mesaj meta verisini korur. API uç noktalarını diğer üretim gizli taşıyan yüzeyler gibi ele alın.
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.
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.
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.
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.
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.
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).
Kart gerekmeden ücretsiz başlayın veya yüksek hacim ve kurumsal için satışla görüşün.
Göndermeye başlaSatışla konuş