Route · Email API
E-posta API
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.
# Kritik e-postayı routing policy üzerinden gönder 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 — entegrasyonu koruyun, kontrol katmanı kazanın host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
Stabil bir sözleşme
Hızlı Ürün Çıkaran Ekipler İçin Pratik Bir API
İ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.
Temsili ürün UI’ı — illustrative data, canlı müşteri metriği değildir.
Neler Alırsınız
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.
Hızlı REST Entegrasyonu
Modern arka uç hizmetleri ve dahili araçlar için net istek/yanıt kalıpları ve öngörülebilir davranış.
Mesaj Yaşam Döngüsü Takibi
Kabul edildi, teslim edildi, geri döndü ve şikayet etti durumlarını takip edin; ürününüz gerçek zamanlı tepki verebilsin.
Operasyonel Görünürlük
Aranabilir günlükler ve olay akışları, kullanıcılar teslimat sorunları bildirdiğinde sorun giderme süresini azaltır.
Yeniden Yazmadan Ölçekleme
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.
Şablon Veri Enjeksiyonu
Dinamik değişkenleri düzgün iletin; transactional şablonlar ürünler arasında tutarlı kalsın.
İdempotent Gönderim Kalıpları
Yeniden deneme senaryolarında deterministik istek işleme stratejileriyle yinelenen gönderimleri önleyin.
Tipik API Akışı
Ekibinizin bir kez uygulayıp tüm transactional senaryolarda yeniden kullanabileceği basit bir kalıp.
1. İstek Gönderin
Hizmetiniz alıcı, şablon verisi ve meta veriyle bir mesaj yükü gönderir.
2. Doğrulama ve Kuyruk
Girdi kontrolleri, bastırma mantığı ve kuyruğa alma teslimat aşamasından önce gerçekleşir.
3. Teslimat
Mesajlar kontrollü gönderim davranışıyla hedef sağlayıcılara yönlendirilir.
4. Olayları Tüketin
Webhooks ve günlükleri kullanarak ürün durumunu güncelleyin ve aşağı akış otomasyonlarını tetikleyin.
Sık Sorulan Sorular
API ve SMTP birlikte kullanılabilir mi?
Evet. Birçok ekip uygulama iş akışları için API, geçiş sırasında eski sistemler için SMTP kullanır.
Her mesaj için olay verisi alıyor muyuz?
Evet. Teslimat, geri dönüş ve şikayet olayları operasyonel ve ürün iş akışları için kullanılabilir.
Yüksek hacimli trafik için uygun mu?
Evet. Aynı API modeli düşük hacimli onboarding aşamalarından sürekli yüksek hacimli gönderime kadar kullanılır.
API gönderimi için SPF, DKIM ve DMARC gerekli mi?
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.
API anahtarları ve izinler nasıl çalışır?
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.
Entegrasyonumuz geçersiz veya yinelenen istekler gönderirse ne olur?
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.
API çağrılarını aşağı akış teslimatla ilişkilendirebilir miyiz?
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.
Email API şifre sıfırlamaları ve OTP kodları için uygun mu?
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ı.
API trafiği için yalnızca HTTPS kullanmalı mıyız?
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.
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).
İlgili ürünler
Her tenant için kritik e-postayı koruyun.
Bu hafta en kritik stream’inizi Sendarix’e taşıyın. Geri kalan her şeyi olduğu yerde bırakın.
