The Zendesk Messaging SDK
Two generations of Zendesk messaging SDK exist and they model support completely differently. Choosing between them is an architecture decision, not a version bump.
The two generations of Zendesk messaging SDK
The older support SDK was ticket-shaped. A customer taps help, fills a form, a ticket is created, and they can come back to a list of their past tickets. It maps one to one onto how the agent side works, which made it easy to reason about and slightly clinical to use.
The newer messaging SDK is conversation-shaped. There is no form. The customer opens a thread and types, exactly as they would in any chat app, and that thread persists forever. Behind the scenes tickets are still created for agents to work, but the customer never sees a ticket. They see a conversation with your company.
That difference sounds cosmetic. It is not. It changes what the customer expects, what your agents see, and how you configure the whole channel.
What persistent conversation actually means
The practical differences once you get past the interface.
| Support SDK style | Messaging SDK style | |
|---|---|---|
| Customer mental model | Filing a ticket | Sending a message |
| History | A list of past tickets | One continuous thread |
| Survives app reinstall | ||
| Follows the user across devices | ||
| Bot and automation layer | ||
| Shares config with the web widget | ||
| Customer sees ticket status |
Persistence, and why it is the headline
On the messaging SDK the conversation is stored server side against the user, not on the device. Sign in on a new phone and the whole history is there. Reinstall the app and nothing is lost. Start on the web widget and continue in the app, and it's the same thread.
For anonymous users, persistence is device-scoped, which is the important footnote. If someone messages anonymously, deletes the app, then reinstalls, that history is generally gone because there was never an identity to attach it to. This is one of the strongest arguments for authenticating users properly.
The other consequence is that conversations do not really end. A customer who messaged eight months ago about billing reopens the same thread to ask about something entirely different. Agents need to be told this, because the context they see is not a fresh ticket, it is a continuing relationship.
Authentication
Both generations authenticate with a signed JWT, and the pattern is identical across iOS, Android and web. Your server holds a secret. It signs a token containing the user identity. Your client passes that token to the SDK.
A typical payload looks roughly like this, with claim names taken from the current SDK reference for the SDK line you are on:
{
"scope": "user",
"external_id": "your-internal-user-id-12345",
"name": "Ada Lovelace",
"email": "ada@example.com",
"iat": 1758499200,
"exp": 1758502800
}Three rules that matter more than the exact schema. Sign server side, always, because a secret in a client binary or in JavaScript is a secret anyone can read. Use your own stable internal identifier as the external ID, not an email address, since emails change and identity should not. And keep expiry short, refreshing the token as part of your normal session refresh rather than issuing something valid for a year.
Get the external ID wrong and you get the classic failure mode: one human being with three Zendesk profiles, each holding part of their history, and agents answering with a third of the context.
What you give up
Messaging is the direction of travel, but it isn't strictly a superset of what came before.
Ticket forms with lots of required fields don't fit a chat interface. If your triage depends on the customer picking a product, a version and a category up front, you replace that with a bot flow, and bot flows are configuration work you did not have before.
The customer also loses visible ticket status. Some audiences want that, particularly B2B and IT support where people genuinely want to see that ticket 4471 is In Progress. A conversation thread does not give them that.
And attachments, file types and message length behave differently to an email-backed ticket. Check the limits against how your customers actually report problems, especially if screenshots and logs are routine.
Choosing
Pick messaging if your customers are consumers, if you want one thread across web and app, if you want bot deflection before an agent is involved, and if your users are signed in so identity is free.
Stay with, or seriously consider, the ticket-shaped approach if structured intake genuinely drives your routing, if customers expect to see ticket status, or if your support model is formal enough that a chat thread would feel wrong.
One thing not to do: run both at once in the same app because migration looks like work. Two support entry points means two histories, two sets of expectations, and a customer who asked in one place and then asked again in the other. If you have to run both during a transition, put a hard date on it and hide the old entry point the moment the new one is live.
Frequently asked questions
How does authentication differ between the SDKs?
The Zendesk conversation SDK uses a JWT you sign, so the conversation follows the user across devices. Zendesk SDK authentication on the older Support SDK is looser, which is why conversations there don't persist the same way.
What is the difference between the Zendesk messaging SDK and the support SDK?
The support SDK is ticket-shaped, with forms and a list of past tickets. The messaging SDK is conversation-shaped, with one persistent thread that follows the user across devices and channels.
Do messaging conversations survive an app reinstall?
For authenticated users, yes, because history is stored against the identity. For anonymous users it's device-scoped and usually lost.
How does authentication work in the messaging SDK?
Your server signs a JWT containing a stable external ID for the user, and the client passes it to the SDK. Never sign in the client.
Can I still collect structured fields with messaging?
Through a bot flow that asks questions before handing off, rather than a form. It's more configuration work but it feels better to the customer.
Does the messaging SDK share configuration with the web widget?
Yes, that's much of the point. Both sit on the same messaging channel, so bot flows and settings are configured once. See the web widget guide.
One conversation, several tickets
Messaging cuts down duplicates without eliminating them, because email and the phone still exist. Ticket Merger closes the gap.
Start free trial14-day free trial. No credit card required.