Building for Shopify Sidekick: App Extensions and the New App Store Rules

If you build Shopify apps, Sidekick app extensions are the most interesting distribution surface to land in a while, and one of the most opinionated. Shopify has been clear about what a well-behaved extension looks like, and reviewers now enforce it. Here's how the pieces fit, drawn from Shopify's Sidekick documentation and from shipping one ourselves for AgentReady.

For the merchant-facing version of what these are, start with Sidekick app extensions, explained. This piece is for the people writing the code.

Two extension types, one rule of thumb

There are two targets, and the split is the whole philosophy.

Data extensions use the admin.app.tools.data target. They register read-only tools that run headlessly in Shopify's sandbox, fetch from your backend, and return structured results Sidekick reads back to the merchant. A tool declares its input schema in a tools.json file and ships with an instructions.md that tells Sidekick when and how to use it.

Action extensions use admin.app.intent.link (navigate to a URL) or admin.app.intent.render (open a UI in the admin). They let Sidekick stage a change and bring up the right screen, but the merchant commits it. Actions declare an intent with a typed schema.

The rule of thumb reviewers hold you to: data tools answer, action tools change, and a change is never silent. Shopify states it plainly: keep data extensions read-only, and "mutations belong in action extensions, where the merchant confirms the change."

The content policy is the part people underestimate

This is where teams trip. Shopify checks your extension's content at two points: at deploy it validates descriptions, instructions, and input schemas, and at runtime it checks the data your tools return before it reaches the conversation. Fail either and the extension is blocked, so designing inside the policy is how you stay reliably available.

What that means in practice:

• Write specific, factual descriptions. "Search and analyze product reviews, ratings, and customer feedback across your store" is the shape they want. "Search extension for your app" gets you nowhere, because Sidekick uses the description to decide when to call your tool. The same applies to every per-tool description in tools.json.
• Do not sell. Upsells, plan-upgrade nudges, competitor comparisons, false urgency, and fabricated endorsements are explicitly not allowed. This is the one place where the usual instinct to market the feature has to be switched off completely. Your tool answers the question and stops.
• Do not steer the assistant. Describing how your tools work together in instructions.md is welcome. Trying to redefine who Sidekick is, override its decisions, or bypass the merchant's confirmation is not.
• Return only what was asked. No embedded directives, no credentials, no customer data the caller didn't request.

If your app is used to putting a "Learn more" or an upgrade prompt on every surface, this is a real adjustment. Sidekick is not a surface you market on. It's one you're useful on.

Auth, limits, and the MCP question

A few constraints shape the build before you write a line of tool logic.

Tools execute in Shopify's sandbox and call your backend with the app session token, not a logged-in dashboard cookie. So your backend endpoint has to authenticate that token rather than a session. Your app needs managed install with token exchange and the latest App Bridge, and you add an extensions_summary to shopify.app.toml, which is required for any app carrying Sidekick-eligible extensions.

On capacity, you get up to 5 intents and 20 tools, with the tool budget shared across data and action extensions. That's plenty, and the discipline it invites is to expose the handful of questions a merchant actually asks rather than mirroring your whole API.

And the question every team asks: can I point Sidekick at my existing MCP server? No. Shopify is explicit that existing MCP servers can't be reused directly. The tools must run in Shopify's sandbox under Shopify auth, and while the schema follows MCP-like patterns, it's Shopify-specific. Static indexing of the tools is what lets Sidekick stay fast.

Shipping it

The mechanics are familiar if you've built extensions before. Scaffold with the Shopify CLI (shopify app generate extension --template app_data for a data tool), fill in tools.json and instructions.md, point each [[extensions.targeting]] entry at its module, and run the local round trip with shopify app dev against the Sidekick preview. The extension only becomes available after shopify app deploy, when Sidekick scans your deployed config and discovers the tools.

One deploy gotcha worth knowing: shopify app deploy is atomic and rejects an unsupported intent type outright. If you've built an action extension whose intent type isn't on Shopify's supported list yet, it will fail the entire deploy, data tools included. Keep an unconfirmed action out of the deploy until its type is registered, so your data extension can ship on its own.

The takeaway for app teams

Sidekick app extensions reward a specific kind of app: one with a clear, answerable question at its core and the discipline to answer it without selling. The content rules aren't red tape; they're Shopify protecting the one thing that makes the assistant worth using, which is that merchants trust it. Build for that and you get a native, in-flow distribution channel most apps don't have yet.

It's early. The surface is in developer preview and Shopify is selecting partners into it. But the apps that learn the etiquette now, while it's quiet, are the ones that will already be fluent when it opens up. If agentic readiness is the bet you're making, we work on exactly this day to day, and we're happy to compare notes.

The extension we shipped is now 17 tools, including a plan-a-post action intent; the merchant-facing inventory is on the AgentReady Sidekick hub.

For the merchant-side model before you build, read what Sidekick app extensions are and how they work.