support

POST `/v1/webhooks/inbound-email`

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

ప్రమాణీకరణ

ఈ ఎండ్‌పాయింట్ పబ్లిక్. దీనికి ఎలాంటి ఆధారాలు మరియు సంస్థ అవసరం లేదు — మన స్వంత మార్కెటింగ్ సైట్ మరియు AI సమాధాన ఇంజిన్‌లు చదివేది ఇదే.

ఈ ఎండ్‌పాయింట్ ఎలాంటి సంస్థ ఐడీని తీసుకోదు. మీ కీ ఇప్పటికే అది ఏ సంస్థకు చెందుతుందో గుర్తిస్తుంది మరియు ప్రతిస్పందన దానికే పరిమితం చేయబడుతుంది.

ప్రయత్నించండి

కోణీయ బ్రాకెట్‌లలో ఉన్న దేన్నైనా మీ స్వంత విలువలతో భర్తీ చేయండి, మరియు కీ ప్లేస్‌హోల్డర్‌ను మీ డాష్‌బోర్డ్ నుండి తీసుకున్న కీతో భర్తీ చేయండి.

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

POST /v1/webhooks/inbound-email