# Zendesk Conversation Extensions vs. Stackable Messaging: creating the rich experiences brands need now more than ever

> What it actually takes to ship a Zendesk Conversation Extension today, how a Stackable Messaging Extension compares, and why the two are about to meet.

By [Rob Bowers](https://www.linkedin.com/in/rob-bowers-72516422/), CTO - Stackable Labs · July 24, 2026

[Zendesk Conversation Extensions](https://developer.zendesk.com/documentation/conversations/messaging-platform/programmable-conversations/conversation-extensions/) are a genuinely good idea. A message lands in the conversation with a button, the customer taps it, and a little web app slides up over the chat: pick a seat, choose a delivery window, confirm a booking. No tab-switching, no "click this link and log in."

## Rich interfaces in messaging

Customers don't want to read about their order in a chat window. They want to *do* something about it: track it, change it, return it, rebook it. And as AI agents take on more of those conversations, the messenger has to become more than a stream of text bubbles.

Zendesk messaging already has a strong foundation for this. Under the hood it runs on Sunshine Conversations, which, as [Thomas Verschoren](https://www.linkedin.com/in/thomasverschoren/) puts it in his excellent [deep dive on Zendesk Internal Note](https://internalnote.com/messaging-sunshine-conversations/), "sits underneath the entire conversational experience in Zendesk." Buttons, carousels and rich article previews render right in the web widget. For anything richer, like a seat map or a payment step, that's where Conversation Extensions come in.

Thomas also makes a point we strongly agree with: "Save extensions for the valuable interactions that genuinely need a richer interface." Those high-value moments are exactly where brands win or lose a customer.

Then you go to build one.

## What it takes today

Here's the path from [Zendesk's own docs](https://developer.zendesk.com/documentation/conversations/messaging-platform/programmable-conversations/conversation-extensions/), for a single Conversation Extension:

1. **Get API access.** Conversation Extensions are delivered through the Sunshine Conversations API, so you need API credentials for your account.
2. **Stand up a server.** Something has to listen for conversation events (a webhook) and decide when to send the extension.
3. **Build and host the web page.** Plain HTML, CSS and JavaScript, served over HTTPS (on an HTTPS site, the webview URL must be HTTPS too).
4. **Send the message yourself.** The extension only exists once your server posts a business message carrying a **webview action** into the conversation. Zendesk notes that the `messagePost` call in its own example incurs Sunshine Conversations Monthly Active User cost.
5. **Add the Webview SDK.** It gives you `hasFeature`, `close`, `setTitle` and `getContext`. Feature support varies by container: `getContext` is always available on web, depends on the app version on iOS and Android, and isn't available on Facebook Messenger. So you check `hasFeature` at runtime and branch.
6. **Verify who you're talking to.** `getContext` returns a signed JWT with the conversation, message and user identifiers. Zendesk is clear that you shouldn't decode and trust it in the browser, so you send it to your server and verify it against Zendesk's published JWKS. Cache those keys, because that endpoint is rate-limited to 5 requests per minute.
7. **Close the loop.** When the customer finishes, you close the webview and, typically, have your server post a confirmation message back into the thread, because once the webview closes, nothing of it remains on screen.

That's a server, a webhook, API credentials, a hosted page, token verification, per-platform feature checks and a message-posting pipeline, all for one experience in one account.

And step 8 doesn't exist: **there's no way to package it.** Zendesk's docs cover delivering a webview into a conversation. They don't cover bundling that experience so another brand can find it, install it, configure it and trust it. If you're a partner who wants to build once and serve many Zendesk customers, you're building that part too.

None of this is a knock on Zendesk. Conversation Extensions are a low-level primitive, and low-level primitives are supposed to give you every knob. It's just a lot of knobs.

## What it takes with Stackable

1. **Scaffold it.** One CLI command sets up the project.
2. **Declare what it needs.** List the capabilities and domains in the manifest. The platform grants exactly that.
3. **Build the UI.** Drop in themed components that already match the brand.

That's it. No webhook server, no token verification, no message pipeline. Publish it to the marketplace and any brand can install it in one click (or keep it private, as your brand's own secret sauce).

> **Or skip even that.** Open up [Stackable AI Studio](https://admin.stackablelabs.com/studio), tell it what you want to build, and two minutes later you have a production-ready experience.

## Companion experiences, not pop-ups

The setup gap is the obvious difference. The bigger one is what you get when you're done.

A Conversation Extension is something you open *from* a message. It overlays the conversation, does one job, and closes.

A Stackable extension is a **companion experience**: it lives *alongside* the conversation, in surfaces around the Zendesk messenger (header, content, footer and footer links). When the customer opens the messenger, the order status, subscription controls or return flow are already there. Nobody has to trigger it.

And because it's always present, it can do more:

- **Read context.** `context.read` gives the extension the customer and the active conversation, so it can show the right order without asking.
- **Act.** `actions.invoke` can open or close the messenger, start a new conversation with tags, fields and metadata, or set conversation fields for your agents.
- **Talk to the conversation.** `messaging.send` posts text, images, files or carousels into the thread, with reply, link, postback and location buttons. The history stays complete for your AI agents and your human ones.
- **Listen to the conversation.** `events:messaging` lets an extension react when a customer taps a postback button, so a message like "Check my order" can light up the order panel.
- **Call your systems safely.** `data.fetch` goes through a Stackable proxy, only to domains on the manifest's allowlist.

Then there's the part Conversation Extensions leave to you entirely: distribution. Every Stackable extension can be listed in the marketplace, where brands see exactly which permissions it asks for before they install. Each install gets its own settings, so one extension serves many brands with different credentials. Submissions go through an automated bundle scan (does the code only do what the manifest declares?) and a review before they go live.

## Side by side

| | Zendesk Conversation Extension | Stackable Messaging Extension |
|---|---|---|
| **Setup** | API credentials, webhook server, hosted page, message pipeline, a few extra aspirin to dull the headaches | Scaffold with the CLI or AI Extension Studio |
| **When it appears** | After your server posts a message with a webview action | Whenever the messenger is open |
| **After the task** | Closes; your server posts a follow-up message | Stays on screen next to the conversation |
| **UI** | Whatever HTML/CSS/JS you build and style | Beautiful, automatically themed components that match your brand |
| **Identity and auth** | Verify a signed JWT on your server - yes, I said server | Built into the platform |
| **Secrets** | Yours to manage | Automatically handled by secure proxy |
| **Talking to the thread** | [Sunshine Conversations API](https://developer.zendesk.com/api-reference/conversations/) from your server | `messaging.send` and `events:messaging` from the extension |
| **Distribution** | Per account, by hand | Marketplace listing, one-click install, per-install settings |

## Coming soon: Conversation Extensions, the easy way

Here's the part we're most excited about, and it started with you. The brands and partners we work with kept asking for one thing: Conversation Extensions without the plumbing.


Everything Stackable already handles (hosting the experience inside a trusted runtime, identity, secrets, theming, talking to the conversation, distribution) is exactly the plumbing that makes Conversation Extensions hard. So we're bringing them onto the platform.

We heard you.

Soon, a Zendesk Conversation Extension will be just another surface in Stackable Messaging. You'll build it with the same SDK and the same components, declare it in the same manifest, and ship it through the same marketplace. Stackable takes care of the webview, the message that launches it, and the token verification behind it.

One extension, one codebase: a companion panel next to the messenger *and* a Conversation Extension inside the thread, installed by any brand in one click.

Available soon to early-access partners first. If you want in before the rest of the pack, [let us know](mailto:developers@stackablelabs.com?subject=Conversation%20Extensions%20early%20access).

## Try it today

Developers: the [developer docs](https://developers.stackablelabs.com) take you from `create` to a live preview, or start in AI Extension Studio with nothing to install. Running a Zendesk messenger and just curious what's possible? [Browse the marketplace](https://stackablelabs.com/marketplace).

Zendesk built a great messaging and AI agent foundation. Stackable is making it a lot easier to build on.