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