Route · Email API
メール API
OTP、パスワードリセット、アカウント通知、請求書、ライフサイクルメッセージを 1 つの API で送信。Sendarix はスケールでの予測可能な挙動のために設計され、壊れやすい統合ではありません。
# 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
安定した契約
迅速にリリースするチーム向けの実用的 API
リクエストの認証、メッセージの送信、結果の追跡を一貫したパイプラインで。各送信はログ、イベント、Webhook で観察できます。
代表的な製品 UI — 例示データであり、実際の顧客指標ではありません。
得られるもの
API は意図的にシンプルです。メッセージの作成と送信、結果の検査、自動化の反応。プロダクトチームが信頼性を損なわずに速く動けます。
高速 REST 統合
明確なリクエスト/レスポンスパターンと、モダンなバックエンドサービスや社内ツール向けの予測可能な挙動。
メッセージライフサイクルの追跡
受理、配信、バウンス、苦情の状態を追跡し、プロダクトがリアルタイムで反応できるようにします。
運用の可視性
検索可能なログとイベントストリームが、ユーザーから配信問題が報告されたときのトラブルシューティング時間を短縮します。
再構築なしでスケール
初期段階のワークロードから高トラフィックフローまで、ボリュームが増えても同じ API 契約を維持。
テンプレートへのデータ注入
動的変数をきれいに渡し、トランザクションテンプレートをプロダクト間で一貫させます。
べき等な送信パターン
決定論的なリクエスト処理でリトライ時の重複送信を防ぎます。
典型的な API フロー
チームが一度実装し、すべてのトランザクションシナリオで再利用できるシンプルなパターン。
1. リクエストを送信
サービスが受信者、テンプレートデータ、メタデータを含むメッセージペイロードを POST します。
2. 検証とキュー
入力チェック、抑制ロジック、キューイングが配信ステージの前に行われます。
3. 配信
メッセージは制御された送信動作で宛先プロバイダーへルーティングされます。
4. イベントの利用
Webhook とログでプロダクトの状態を更新し、下流の自動化をトリガーします。
よくある質問
API と SMTP を併用できますか？
はい。多くのチームはアプリケーションワークフローに API を、移行中のレガシーシステムに SMTP を使います。
各メッセージのイベントデータは取得できますか？
はい。配信、バウンス、苦情のイベントが運用とプロダクトのワークフローで利用できます。
高トラフィックに適していますか？
はい。同じ API モデルが低ボリュームのオンボーディングから持続的高ボリューム送信まで使われます。
API 送信に SPF、DKIM、DMARC は必要ですか？
送信ドメインの認証を強く推奨します。受信側がメールを評価する上で改善し、本番トラフィックの前提となります。
API キーと権限はどう機能しますか？
環境やサービスごとにキーを発行し、各キーができることを制限できます。ステージング、CI、本番を分離できます。
無効または重複リクエストを送るとどうなりますか？
API は不正なペイロードに対して明確な検証エラーを返します。リトライではアプリ層で安定した識別子を使い、ユーザー向けメールの二重送信を避けてください。
API 呼び出しと下流の配信を関連付けられますか？
はい。メッセージ ID とイベントタイムラインで、特定の API 送信を受理、配信、バウンス、遅延の結果に結び付けられます。
パスワードリセットや OTP にメール API は向いていますか？
はい。低遅延の期待、高い可視性、認証やリスクシステムとの密接な結合が典型的なトランザクション用途です。
API トラフィックは HTTPS のみにすべきですか？
はい。TLS は転送中の認証情報とメタデータを保護します。API エンドポイントは他の本番の秘密を扱う面と同様に扱ってください。
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).
関連製品
