Monitor · Webhooks
Email Webhooks
Teslimat güncellemeleri için panoları yoklamayı bırakın. Kabul edildi, teslim edildi, geri döndü ve şikayet olaylarını doğrudan uygulamanıza ve iş akışlarınıza iletin.
Temsili ürün UI’ı — illustrative data, canlı müşteri metriği değildir.
Kara kutudan event stream’e
Olay Güdümlü E-posta Operasyonları
Webhooks ile ürün durumunu senkronize edin, yeniden denemeleri tetikleyin, ekipleri uyarın ve müşteri durumunu doğru tutun.
# 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
Webhook Yetenekleri
Webhooks e-postayı ürününüzün gerçek zamanlı olarak anlayabileceği bir olay akışına dönüştürür.
Teslimat Durumu Senkronizasyonu
Mesajlar kabul edilenden teslim edildi veya geri döndü durumuna geçerken kullanıcıya dönük durumu güncelleyin.
Başarısızlık Otomasyonu
Geçici veya kalıcı başarısızlıklar algılandığında yeniden deneme yollarını ve dahili uyarıları tetikleyin.
İtibar Koruması
Şikayet ve geri dönüş olaylarını otomatik işleyerek kötü adreslerin gelecekteki gönderimlerden çıkmasını sağlayın.
İş Akışı Entegrasyonları
Olayları CRM, veri ambarı, kuyruk işçileri ve olay müdahale sistemlerine besleyin.
İmza Doğrulama
Gelen webhook imzalarını doğrulayın; yalnızca güvenilir Sendarix olayları işlensin.
Yeniden Denemeye Dayanıklı Tüketiciler
Yinelenen teslimleri ve gecikmiş olayları güvenle işleyen idempotent işleyiciler tasarlayın.
Webhook Yaşam Döngüsü
Güvenilir olay güdümlü otomasyonlar kurmak için doğrudan bir akış.
1. Mesaj Gönder
Mesaj API veya SMTP üzerinden teslimat boru hattına girer.
2. Olay Üretildi
Teslimat sistemi durum olayları oluşturur (kabul edildi, teslim edildi, geri döndü, şikayet).
3. Webhook Teslim Edildi
Olaylar anında işleme için uç noktanıza gönderilir.
4. Uygulama Tepki Verir
Sistemleriniz kullanıcı durumunu günceller, işleri tetikler veya ekipleri otomatik bilgilendirir.
Sık Sorulan Sorular
Webhooks yoklamanın tamamen yerini alabilir mi?
Çoğu olay güdümlü iş akışı için evet. Ekipler yine de geçmiş analiz ve raporlama için analitik kullanır.
Hangi olaylarla başlamak en önemli?
Önce teslim edildi, geri döndü ve şikayet ile başlayın. Ardından etkileşim veya özel iş akışı olaylarına genişleyin.
Webhooks yalnızca büyük sistemler için mi?
Hayır. Küçük uygulamalar bile anında durum senkronizasyonu ve daha az manuel destek hata ayıklamasından yararlanır.
Webhook isteklerinin gerçek olduğunu nasıl doğrulamalıyız?
Paylaşılan gizlilikler, imzalar veya sağlandığında HMAC başlıkları kullanın; yeniden oynatmaları engellemek için zaman damgalarını doğrulayın; üretim durumunu güncellemeden önce kontrollerden geçmeyen yükleri reddedin.
Webhook tetiklendiğinde uç noktamız kapalıysa ne olur?
Yeniden deneme politikalarına güvenin ve işleyicileri idempotent yapın. Yinelenen yeniden denemelerin veritabanınızı veya kullanıcı bildirimlerini bozmaması için alınan olay kimliklerini günlükleyin.
Webhook işleme HTTP isteğinde senkron olmalı mı?
Genellikle hayır. Hızlı onaylayın, işi bir iş çalıştırıcıya kuyruğa alın ve yavaş görevler zaman aşımına ve gereksiz yeniden denemelere yol açmasın diye asenkron işleyin.
Aynı olayı birden fazla dahili servise dağıtabilir miyiz?
Evet, bir mesaj veri yolu veya yönlendirici aracılığıyla. Doğrulayan ve yükleri normalize eden tek bir giriş tutun, ardından faturalama, CRM, veri ambarı veya uyarı tüketicilerine dağıtın.
Webhooks geri dönüş ve şikayet yönetimine nasıl yardımcı olur?
Bastırma listelerini güncellemenize, riskli kampanyaları duraklatmanıza veya hesapları destek biletlerinden saatler sonra değil neredeyse gerçek zamanlı işaretlemenize olanak tanır.
Staging ve üretim için ayrı webhook URLlerine ihtiyacımız var mı?
Şiddetle önerilir. İzole uç noktalar test olaylarının canlı kullanıcı verisine dokunmasını önler ve kimlik bilgilerini bağımsız döndürmeyi kolaylaştırır.
What is the format of webhook payloads?
All payloads are JSON with a consistent envelope: event type, timestamp, message ID, and event-specific data. See the Payload Examples section for full schemas.
What happens if our endpoint returns a non-2xx response?
Any response outside the 2xx range triggers a retry. Timeouts, connection refusals, and DNS failures also count as failures and trigger retry logic.
How long does Sendarix wait for our endpoint to respond?
Default timeout is 10 seconds. If your endpoint does not respond within this window, the request is considered failed and enters the retry queue.
Can we filter which events we receive?
Yes. Configure event type filters per endpoint to receive only the events relevant to your integration (e.g., bounces and complaints only).
What HTTP methods does Sendarix use for webhook delivery?
Sendarix sends POST requests only. If your endpoint receives a GET, PUT, PATCH, or DELETE request to the webhook URL, return 405 Method Not Allowed. This prevents accidental processing of unrelated traffic that may hit your endpoint.
How do we handle webhooks during deployment downtime?
Sendarix queues events during the retry window. If your endpoint is down for less than 5 hours, all events are preserved and delivered when your endpoint returns. For extended downtime (maintenance windows, incidents), queue events in Sendarix and process them after recovery via the event replay API.
Should our webhook endpoint be idempotent across different event types?
Yes. Process the event_id regardless of event_type. A given event_id represents one specific event (e.g., evt_abc123 = bounce for msg_xyz). If you receive evt_abc123 twice, return 200 OK on the second attempt without reprocessing. The event_id is globally unique across all event types.
How do we test webhooks in a staging environment without affecting production data?
Configure a separate webhook endpoint in your staging environment with its own secret. Use the Sendarix sandbox mode to send test events that do not count against production limits or affect real recipient addresses. This allows integration testing without generating fake suppression entries or polluting analytics.
What is the maximum number of events we can receive per second?
Sendarix delivers events in real time with no artificial rate limit on webhook delivery. During burst scenarios (e.g., a campaign delivery wave), your endpoint may receive hundreds of events per second. Design your endpoint to scale horizontally and your job queue to absorb these spikes. Monitor queue depth via the API to detect when processing falls behind.
İlgili ürünler
Start Receiving Email Events in Real Time
Configure your webhook endpoint in minutes. Get delivery, bounce, complaint, open, and click events as they happen.
