support
POST /v1/webhooks/inbound-email
Ingest a customer's support reply from the mail edge.
認証
このエンドポイントは公開されています。認証情報や組織情報は不要で、当社のマーケティングサイトやAI回答エンジンが読み取っているものと同じです。
このエンドポイントは組織IDを受け付けません。お使いのキーによって所属する組織がすでに特定されており、レスポンスはその組織にスコープされます。
試してみる
アングルブラケット内のすべてをご自身の値に置き換え、キーのプレースホルダーをご利用中のダッシュボードのキーに置き換えてください。
curl -X POST https://api.zinndigital.com/v1/webhooks/inbound-email \
-H "Content-Type: application/json" \
-d '{ "from": <string>, "message_id": <string> }'ログインしていますか？ダッシュボード内のAPIコンソールでは、実際の組織IDやお客様ご自身のキーが自動入力され、ライブAPIに対してリクエストが実行されるため、実際のレスポンスを確認することができます。 API コンソールでこのエンドポイントを開く
詳細
Unauthenticated by design — the caller is a Cloudflare Email Routing Worker with no Zinn® credential, so an HMAC over "<timestamp>\n<body>" in X-Zinn-Signature is the authentication. The timestamp is inside the signed material and its skew is bounded, so a captured request cannot be replayed later. This is the inbound half of support email. Before it existed the platform sent notifications from an address that accepted mail and discarded it: a customer replied, nothing happened, and neither they nor the waiting staff member was told. The ticket is resolved from a signed token inside the Message-ID we set on the outbound notification — nothing in the body, the From address or any other header selects a tenant, because all of those are chosen by whoever sent the mail. Redelivery is the normal case, not the exception: email is at-least-once and a lost response guarantees a retry, so a message already filed answers 200 with duplicate: true rather than appending a second copy. ⛔ Unlike the gateway webhooks, a message that cannot be routed is answered 422, not 200. A 2xx tells the Worker to accept the mail, and an accepted message that reaches no ticket is the exact defect this endpoint exists to remove; 422 makes the Worker reject it so the sender's own mail server bounces it back to the customer.
パラメータ
| 名前 | タイプ | 必須 | これがその内容です |
|---|---|---|---|
X-Zinn-Timestamp (header) | string | はい | Unix seconds. Inside the signed material; skew-bounded to five minutes. |
X-Zinn-Signature (header) | string | はい | sha256=<hex> HMAC over "<timestamp>\n<body>". |
リクエスト本文
| 名前 | タイプ | 必須 | これがその内容です |
|---|---|---|---|
from | string | はい | The envelope sender. Forgeable, and treated as such — it is checked against the ticket's org and the answer becomes a flag, never a permission. |
to | string | いいえ | — |
message_id | string | はい | The message's own Message-ID. Stored, and unique, so a redelivery cannot append twice. |
in_reply_to | string | いいえ | Carries the signed ticket token when the customer replied to one of our notifications. |
references | string | いいえ | The full thread chain. Searched as well as in_reply_to, because a reply to the third message in a thread puts our id here and not there. |
subject | string | いいえ | — |
text | string | いいえ | The message body. Quoted history is trimmed engine-side and the result is length-bounded. |
返信
| 名前 | タイプ | 必須 | これがその内容です |
|---|---|---|---|
ticket_id | string | はい | — |
duplicate | boolean | はい | This exact message had already been filed — a success, not an error. |
sender_verified | boolean | はい | Whether the sender is a known address on the ticket's org. false still files the message, flagged for staff. |
reopened | boolean | はい | Whether filing it moved a solved ticket back to open. |
このエンドポイントが返すエラー
400 · 422 · 503