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 کنسول آپ کی حقیقی تنظیم کی آئی ڈی اور آپ کی اپنی کلید خود بخود پُر کر دیتا ہے، اور لائیو 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