support

POST `/v1/webhooks/inbound-email`

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

Аутентификация

Бұл соңғы нүкте жалпыға қолжетімді. Ол ешқандай тіркелгі деректерін және ешқандай ұйымды қажет етпейді — оны біздің өзіміздің маркетингтік сайтымыз бен жасанды интеллект жауап беретін жүйелеріміз оқиды.

Бұл соңғы нүкте ұйым идентификаторын қабылдамайды. Сіздің кілтіңіз оның қай ұйымға тиесілі екенін өзі анықтайды және жауап соған шектеледі.

Әрекет етіп көру

Бұрыштық жақшалардағы кез келген нәрсені өз мәндеріңізбен, ал кілт орналастырушысын басқару тақтасынан алынған кілтпен алмастырыңыз.

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

Жүйеге кіргенсіз бе? Бақылау тақтасындағы API консолі ұйымыңыздың нақты идентификаторы мен жеке кілтіңізді автоматты түрде толтырады да, нақты жауапты көре алуыңыз үшін сұрауды тікелей жұмыс істеп тұрған 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.

Параметрлер

Аты	Tүрі	Міндетті	Мазмұны
`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>"`.

Сұрау денесі

Аты	Tүрі	Міндетті	Мазмұны
`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.

Жауап

Аты	Tүрі	Міндетті	Мазмұны
`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

POST /v1/webhooks/inbound-email