Integration

Zendesk, and keeping one conversation out of two threads

A Zendesk integration turns an escalated Telegram conversation into a ticket and keeps replies flowing in both directions, so the customer stays in Telegram while the agent stays in Zendesk. The hard part is identity: without a stable requester mapping, every conversation creates a new user.

Zendesk integration: auth, limits and availability

Auth model: API key
Rate limit: Per account, varying by plan; 429 with Retry-After
GCC availability: No regional restriction; data residency on some plans
Data flow: 5 hops, worker-mediated

As of 2025-10-01, Telegram Bot API 13.4

Why this integration exists

A support team that already runs on Zendesk has its SLA reporting, its macros and its agent workflow there, and none of that should move because a new channel appeared. So the requirement is not to replace Zendesk; it is to make Telegram behave like another channel feeding it, with the conversation staying where the customer already is.

The identity problem is the one that decides whether this works. Zendesk keys tickets to a requester, and a Telegram user arrives with a numeric id and a display name — no email, usually no phone. Creating a requester per conversation produces a support history fragmented across dozens of users who are all the same person, which quietly destroys the reporting the team adopted Zendesk for in the first place.

The second problem is loops. The bot posts a customer message into the ticket; Zendesk's own triggers fire; a notification comes back; the bot posts it to the customer. Without an explicit marker distinguishing bot-originated comments from agent ones, a support thread can echo itself into an infinite exchange — which is exactly as embarrassing in front of a customer as it sounds.

How the data actually moves

The requester map is what keeps one customer as one Zendesk user across every conversation they ever have.

An API token paired with an agent email, or an OAuth token for a multi-account integration, held as a Worker secret. The integration authenticates as a dedicated agent rather than as a person, so ticket history attributes automated activity correctly and does not break when a team member leaves.

Auth model: API key

Their limits, and what they mean for you

Zendesk applies per-account rate limits that vary by plan, returning 429 with a Retry-After header.

The header is honoured rather than replaced with a local backoff. Support traffic is bursty by nature, so hitting the limit during an incident is exactly when it matters.

Tickets are associated with a requester, and requesters are ordinarily identified by email.

A Telegram user has no email. A stable external identity mapping is created on first contact, or every conversation fragments the customer's history.

Comments can be public or internal, and the distinction drives what the customer sees.

Only public comments are relayed to Telegram. Relaying an internal note to a customer is a memorable failure and is trivially avoidable.

Triggers and automations fire on API-created tickets exactly as on any other.

Every existing automation runs. Mapping them is part of scoping, because an auto-reply email to a requester with no email address fails in confusing ways.

How it fails, and what happens when it does

The bot and Zendesk echo each other into a loop.

Bot-originated comments carry a marker and are ignored on the way back. Without it a support thread can duplicate itself indefinitely in front of the customer.

One customer becomes many Zendesk users.

The requester map keys on the Telegram user id. Retrofitting a merge later is possible and unpleasant, which is why the mapping is decided before the first ticket.

An internal note is relayed to the customer.

Only public comments cross the boundary, and the check is explicit rather than inferred from formatting. Agents write internal notes assuming privacy and are right to.

A rate limit is hit while relaying an agent reply.

The relay queues and retries, so the agent's reply arrives late rather than never. Silently dropping it leaves the agent believing they answered.

Availability in the UAE and the wider GCC

Global

No regional restriction. Data residency options exist on some plans and are worth confirming where a regulator cares.

Existing Zendesk customers

The intended case. If your team is not already on Zendesk, this integration is a reason to reconsider rather than to adopt it.

Suite versus Support-only plans

API availability and rate limits vary by plan. Confirm before scoping, since limits shape the relay design rather than merely constraining it.

Sandbox availability

Available on higher plans and genuinely useful here, because trigger side effects are the main source of surprises.

When not to use this integration

Your team is not already on Zendesk. Adopting a helpdesk to integrate with it is the tail wagging the dog.
Your support volume is a handful of conversations a day. A Telegram forum topic will handle it and cost nothing.
You want the bot to close tickets automatically. Resolution is a judgement, and automatic closure produces SLA figures nobody believes.
Nobody can tell you what your triggers do. They will fire on every bot-created ticket and the surprises are discovered in front of customers.

What it runs on

Component	Version	Why
Cloudflare Workers	current	Ticket creation, comment relay and webhook handling.
Cloudflare D1	current	Requester map, ticket-to-conversation links and relay state.
Zod	4.4	Validation of webhook payloads and API responses.
grammY	1.45	The customer-facing conversation and escalation handoff.

Questions that come up during scoping

How does a Telegram user become a Zendesk requester?

Through a stable mapping created on first contact and keyed on the Telegram user id. Without it every conversation creates a new user and the customer's history fragments, which quietly ruins the reporting the team adopted Zendesk for.

What stops the bot and Zendesk replying to each other forever?

Bot-originated comments carry a marker and are ignored when they come back through the webhook. It is a small detail and its absence produces a thread that duplicates itself in front of the customer.

Can agents keep using internal notes?

Yes, and only public comments are relayed. The check is explicit rather than inferred, because agents write internal notes assuming privacy and that assumption has to hold.

What happens to our existing triggers?

They fire on bot-created tickets exactly as on any other. That includes email auto-replies to a requester who has no email address, which fails in ways that are confusing until someone maps the automation.

Should the bot close tickets?

No. Resolution is a judgement and automatic closure produces SLA numbers your team will stop trusting. The bot relays and escalates; a person decides when something is resolved.

What happens if we are rate-limited mid-conversation?

The relay queues and retries with the Retry-After value Zendesk supplies. The agent's reply arrives late rather than never, which matters because dropping it silently leaves the agent believing they answered.