Monitor · Webhooks
メール Webhooks
配信の更新のためにダッシュボードをポーリングするのはやめましょう。受理、配信、バウンス、苦情のイベントをアプリとワークフローに直接プッシュします。
代表的な製品 UI — 例示データであり、実際の顧客指標ではありません。
ブラックボックスからイベントストリームへ
イベント駆動のメール運用
Webhook でプロダクトの状態を同期し、リトライをトリガーし、チームにアラートし、顧客の状態を正確に保ちます。
# 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" });
# Drop-in SMTP — 既存統合を維持し control plane を追加 host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
Webhook の機能
Webhook はメールをブラックボックスから、プロダクトがリアルタイムで推論できるイベントストリームに変えます。
配信状態の同期
メッセージが受理から配信またはバウンスへ移るにつれて、ユーザー向けの状態を更新。
失敗の自動化
一時的または永続的な失敗を検出したときにリトライパスと社内アラートをトリガー。
レピュテーションの保護
苦情とバウンスイベントを自動処理し、悪いアドレスを将来の送信から除外。
ワークフロー統合
イベントを CRM、データウェアハウス、キューワーカー、インシデント対応システムに供給。
署名検証
受信 Webhook の署名を検証し、信頼できる Sendarix のイベントのみを処理。
リトライ安全なコンシューマ
重複配信と遅延イベントを安全に処理するべき等ハンドラを設計。
Webhook のライフサイクル
信頼できるイベント駆動自動化を構築するための直線的なフロー。
1. メッセージを送信
メッセージは API または SMTP から配信パイプラインに入ります。
2. イベント生成
配信システムがステータスイベント（受理、配信、バウンス、苦情）を作成。
3. Webhook 配信
イベントが即時処理のためにエンドポイントに POST されます。
4. アプリが反応
システムがユーザー状態を更新し、ジョブをトリガーするか、チームに通知します。
よくある質問
Webhook はポーリングを完全に置き換えられますか？
ほとんどのイベント駆動ワークフローでははい。チームは履歴分析とレポートのために分析を使い続けます。
最初に重要なイベントはどれですか？
配信、バウンス、苦情から始めてください。その後エンゲージメントやカスタムワークフローイベントに拡張。
Webhook は大規模システム専用ですか？
いいえ。小さなアプリでも即時の状態同期と手動サポートデバッグの削減の恩恵があります。
Webhook リクエストが本物かどうかをどう検証しますか？
共有秘密、署名、または提供された HMAC ヘッダーを使用し、タイムスタンプを検証してリプレイをブロックし、チェックに失敗したペイロードは本番状態を更新する前に拒否します。
Webhook が発火したときにエンドポイントがダウンだったら？
リトライポリシーに頼り、ハンドラをべき等にしてください。受信したイベント ID をログに記録し、リトライからの重複がデータベースやユーザー通知を破壊しないようにします。
Webhook 処理は HTTP リクエスト内で同期すべきですか？
通常はいいえ。すぐに応答し、ジョブランナーにキューイングして非同期に処理し、遅いタスクがタイムアウトと不要なリトライを引き起こさないようにします。
同じイベントを複数の内部サービスにファンアウトできますか？
はい。メッセージバスまたはルーター経由で。単一のイングレスで検証しペイロードを正規化してから、請求、CRM、データウェアハウス、アラートのコンシューマに配布します。
Webhook はバウンスと苦情の処理にどう役立ちますか？
抑制リストの更新、リスクのあるキャンペーンの一時停止、アカウントのフラグ付けをほぼリアルタイムで行え、サポートチケットで数時間後に問題を発見する代わりになります。
ステージングと本番で別の Webhook URL が必要ですか？
強く推奨します。分離されたエンドポイントはテストイベントが本番のユーザーデータに触れるのを防ぎ、認証情報を独立してローテーションしやすくします。
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.
関連製品
Start Receiving Email Events in Real Time
Configure your webhook endpoint in minutes. Get delivery, bounce, complaint, open, and click events as they happen.
