The Zendesk Messaging API
People search for this expecting an endpoint on the Support API. It's a different product, with a different base URL and a different model of a conversation.
The Zendesk messaging API: two products, one word
Zendesk messaging is the modern live conversation channel: the web widget, the mobile SDKs, WhatsApp, Facebook Messenger and the rest. It replaced the older Chat product for new accounts, and the conceptual model is different.
Underneath it sits Sunshine Conversations, which Zendesk acquired and which provides the conversation platform and its API. When people talk about the Zendesk messaging API, that's usually what they mean.
The Support API, the one at /api/v2/ on your subdomain, is about tickets. It'll show you the ticket a messaging conversation produced. It will not let you send a message into a live conversation, hand a chat to a bot, or receive an inbound message the moment it arrives.
So the first question is not "which endpoint" but "which product". Get that wrong and you spend a day looking for a send-message endpoint that was never going to be there.
Conversations are not tickets
The model differs in ways that matter for design.
That last point is where most confusion lives. A customer who messages three times over a week may generate one ticket or three, depending on configuration and timing, and neither behaviour is wrong. Decide what you want before you build reporting on top of it.
For how the channel behaves for agents and customers rather than for developers, the Zendesk messaging guide covers the product side.
What the Sunshine Conversations API gives you
A different base URL, its own credentials in the form of an app-scoped key ID and secret, and a resource model built around apps, users, conversations and messages.
Broadly, it lets you do four things the Support API cannot.
Exact paths, payload shapes and which parts require which plan all change more often than the ticketing API does, so check the current Sunshine Conversations reference rather than trusting a code sample you found. That advice isn't a cop-out, it's the actual failure mode: half the messaging examples on the internet predate a rename.
Webhooks and the shape of an integration
Real-time is the whole point of messaging, and polling defeats it. So the standard architecture is webhook-driven.
You register an endpoint, choose the events you care about, and Zendesk posts to you when a message arrives, a conversation starts or a participant joins. Your service does whatever it does and, if it wants to reply, calls the API to post a message back.
Three engineering notes that apply regardless of the exact payload.
Verify the signature. Webhook deliveries are signed. An unverified endpoint accepting conversation events is an open door.
Respond immediately and process asynchronously. Do the work on a queue. A slow handler causes retries, and retries cause duplicate processing.
Expect redelivery. At-least-once delivery is normal, so make your handler idempotent on the message ID. This is exactly the same discipline the Zendesk webhooks guide describes for the ticketing side.
Which one do you need
Embedding chat in a website or app. Use the widget or the messaging SDKs. You don't need the API at all.
Reading what was said, after the fact. The Support API. Messaging conversations produce tickets and the comments are readable there.
Reacting to a message the second it lands. Sunshine Conversations webhooks.
Sending a message into a live conversation from your own system. Sunshine Conversations API.
Building a bot. Either the built-in bot builder, or Sunshine Conversations if you want your own logic and your own model behind it.
And one honest note on plans. Messaging capability, the number of channels, and the availability of the conversations API differ by plan and by product, so confirm what your account actually includes before you design around it.
Frequently asked questions
Which API do I need for messaging?
Depends what you're building. The Zendesk Sunshine Conversations API carries the conversation itself and is the basis of any custom Zendesk messaging integration. The older Zendesk Chat API covers legacy live chat, and the Zendesk conversations API is the modern name. A Zendesk messaging webhook is how you receive events rather than poll for them.
Is the Zendesk messaging API part of the Support API?
No. Messaging runs on Sunshine Conversations, with its own base URL and its own app-scoped credentials. The Support API only shows you the tickets messaging produces.
Can I send a message into a live chat from the ticket API?
Not in the live conversation sense. Ticket comments update the ticket. Posting into an active messaging conversation is a Sunshine Conversations call.
How do I get messages in real time?
Webhooks. Register an endpoint, verify the signature on every delivery, respond fast and process the work asynchronously.
Does one messaging conversation always become one ticket?
No. Whether continued messages append to an existing ticket or create a new one depends on configuration and timing, which matters a lot for reporting.
Do I need the API to put chat on my website?
No. The web widget and the mobile SDKs cover embedding. The API is for programmatic sending, receiving and custom clients.
Messaging and email, one customer, two tickets
Ticket Merger merges duplicate Zendesk tickets on requester, subject keywords and ticket fields inside a time window, whichever channel they arrived on.
Start free trial14-day free trial. No credit card required.