support

POST `/v1/webhooks/inbound-email`

Ingest a customer's support reply from the mail edge.

Xác thực

Điểm cuối này là công khai. Nó không yêu cầu thông tin xác thực hay tổ chức nào — đây chính là nội dung mà trang web tiếp thị và các công cụ trả lời bằng AI của chúng tôi đọc.

Endpoint này không nhận ID tổ chức. Khóa của bạn đã xác định tổ chức mà nó thuộc về và phản hồi được giới hạn trong phạm vi đó.

Dùng thử

Thay thế bất kỳ nội dung nào trong ngoعل (angle brackets) bằng giá trị của riêng bạn và trình giữ chỗ key bằng một key từ trang tổng quan của bạn.

curl -X POST https://api.zinndigital.com/v1/webhooks/inbound-email \
  -H "Content-Type: application/json" \
  -d '{ "from": <string>, "message_id": <string> }'

Đã đăng nhập? Bảng điều khiển API trong trang quản lý của bạn sẽ tự điền ID tổ chức thực tế và khóa của riêng bạn, sau đó chạy yêu cầu đối với API trực tiếp để bạn có thể xem phản hồi thực tế. Mở điểm cuối này trong bảng điều khiển API

Chi tiết

**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.

Tham số

Tên	Loại	Bắt buộc	Nội dung này là gì
`X-Zinn-Timestamp (header)`	`string`	Có	Unix seconds. Inside the signed material; skew-bounded to five minutes.
`X-Zinn-Signature (header)`	`string`	Có	`sha256=<hex>` HMAC over `"<timestamp>\n<body>"`.

Nội dung yêu cầu

Tên	Loại	Bắt buộc	Nội dung này là gì
`from`	`string`	Có	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`	Không	—
`message_id`	`string`	Có	The message's own `Message-ID`. Stored, and unique, so a redelivery cannot append twice.
`in_reply_to`	`string`	Không	Carries the signed ticket token when the customer replied to one of our notifications.
`references`	`string`	Không	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`	Không	—
`text`	`string`	Không	The message body. Quoted history is trimmed engine-side and the result is length-bounded.

Phản hồi

Tên	Loại	Bắt buộc	Nội dung này là gì
`ticket_id`	`string`	Có	—
`duplicate`	`boolean`	Có	This exact message had already been filed — a success, not an error.
`sender_verified`	`boolean`	Có	Whether the sender is a known address on the ticket's org. `false` still files the message, flagged for staff.
`reopened`	`boolean`	Có	Whether filing it moved a `solved` ticket back to `open`.

Các lỗi điểm cuối này có thể trả về

400 · 422 · 503

POST /v1/webhooks/inbound-email