Opinion: How Shopify Sidekick can unlock apps
Adding the “Completion Layer” for Shopify’s Extension Ecosystem with Sidekick
On the back of DotDev 2026, if it isn’t already obvious here is another reminder - Sidekick is the goto for merchants and having Sidekick extensions is a must-have. As soon it was available for us to build on, we started adding our capabilties to it and continue to see waves of merchants using those with low/no nudge to use those extensions week on week.
Playing it forward, it is not hard to imagine merchants getting super comfortable leveraging Sidekick for doing the mundane or technically complex but structured workflows, especially without a lot of nudging. The more that happens, it is visible to see Sidekick act as the OS-like layer for Shopify merchants to work their commerce stack/technologies, so it just makes sense to connect those dots. This post is my take on the biggest opportunity to get there as an ecosystem with the Shopify Extensibility framework. The first principle driving this whole note is the shared common goal - increase value for time spent by merchants focussing on their business problems, not the configurations.
What Sidekick Is Today
Most already know, for those that don’t - Sidekick is a powerful, context-aware assistant embedded in the Shopify admin. It can guide merchants through complex tasks, take actions on their behalf, and answer questions grounded in live store data and other apps.
But today, Sidekick to most is reactive and stateless. It responds to what a merchant asks when they remember to ask. It has no concept of:
What a task’s done state looks like
Whether the merchant actually finished what they started
Whether an app, workflow, or extension that depends on that task is now correctly configured
What happens if the merchant stops halfway
What should surface tomorrow if the task is still incomplete
For merchants, this means setup feels guided but unverified. For app developers, it means handing off to Sidekick is a one-way door - there’s no signal back that the job is done.
The Missing Primitive: Completion
Every meaningful merchant task has 5 phases:
Guidance
Today - Sidekick does this well
What's Missing - Nothing much
Execution
Today - Sidekick can act on behalf of the merchant
What’s Missing - Coverage is partial - not all surfaces
Verification
Today - Not supported
What’s Missing - Sidekick cannot confirm actual store state post-action
Persistence
Today - Not supported
What’s Missing - Incomplete tasks disappear when the session closes
Re-prioritization
Today - Not supported
What’s Missing - No mechanism to re-surface tasks based on business impact or role
Without verification, there is no closure. Without closure and persistence, there is no reliable completion. And without reliable completion, Sidekick cannot be trusted as a setup or onboarding layer by apps or by merchants.
Where This Breaks Down - By Surface
Online Store / Theme App embeds enabled on the wrong theme. Sections placed in the wrong template. Blocks removed after a theme switch. No API exists to query placement state - so neither the app nor Sidekick can verify what’s actually live.
Point of Sale POS extensions are configured inside the POS app itself - a surface Sidekick has no presence in. Enablement per location, staff role permissions, and surface coverage (iOS/Android) are not exposed via any Admin API.
Checkout & Customer Account Extensions Extensions must be manually placed in the checkout or accounts editor. Placement, step, visibility, and conflict state are not queryable by apps. Sidekick can guide placement but cannot confirm it happened correctly.
Shopify Flow Apps that ship Flow templates have no way to confirm a merchant installed, activated, and successfully ran the required workflows. Silent failures in workflow run history go unnoticed.
What “Completion Layer” Means - The Proposed Model
Here is the ask to Shopify - introduce a set of platform primitives that, together, make Sidekick a reliable completion engine:
1. Extension State APIs Queryable, per-surface APIs that expose the actual live state of every extension type - theme embeds, checkout placements, POS enablement, Flow workflow status. Without these, verification is impossible for anyone.
Side note - here is an example of how we are doing this without primitives, ie working around
2. Connected Actionable Health Check Flows
Setup breaks silently. Themes get switched. Workflows get deactivated. Staff change configurations without realizing the downstream impact.
Apps (somehow) manage to run scheduled health checks against the extension state APIs available per merchant - on a daily or weekly cadence. For example - we do that for whatever surfaces it is already supported or we have sorta signal-oriented heartbeats for where it is not supported (like POS extensions). But it is not useful without actionable base state APIs per extension surface area - and being able to programmatically inject a “task” into Sidekick when a previously healthy state is found to be broken:
Example 1: Theme App Embed Health Check
Let’s say the app has managed to run a periodic state check for all merchants, having the safe/singular app_“task_id” to push into a queue for merchant to act on as needed. Running this check itself is costly (rate limits and other infra usage), so unless the merchant has finished it or ignored it, the frequency can be reduced
{
"extension_health_check_id": "theme-embed-health", //app-namespaced
"check": {
"type": "theme_embed_enabled",
"theme_role": "main",
"app_id": "your-app-id",
},
"on_failure": {
"inject_task": {
"task_id": "re-enable-embed-live-theme",
"title": "Your app embed was disabled on your live theme",
"surface": "theme",
"importance": "critical",
"contributed_by": "app",
"potential_fixes": [<<prompts to create Sidekick tasks to resolve the issue>>]
}
}
}
Example 2: POS Extension Health Check — Multi-Location, Role-Aware
A similar but more painful case on POS extensions
{
"extension_health_check_id": "pos-extension-all-locations", //app-namespaced
"check": {
"type": "pos_extension_enabled",
"app_id": "your-app-id",
"extension_handle": "your-pos-extension-handle",
"scope": "all_active_locations",
"surfaces": ["ios", "android"],
"require_staff_role_access": {
"roles": ["sales_staff", "store_manager"],
"permission": "pos_extension_access"
}
},
"on_failure": {
"inject_task": {
"task_id": "pos-extension-location-gap",
"title": "POS extension not active at one or more locations",
"surface": "pos",
"importance": "high",
"contributed_by": "app",
"failure_detail": {
"include_affected_locations": true,
"include_affected_roles": true
},
"potential_fixes": [<<prompts to create Sidekick tasks to resolve the issue>>]
}
}
}
What this check evaluates — via the proposed posExtensions GraphQL query:
query {
posExtensions(appId: "your-app-id", handle: "your-pos-extension-handle") {
nodes {
location {
id
name
isActive
}
enabled
surfaces
staffRoleAccess {
role
hasPermission
}
lastConfiguredAt
}
}
}
Example failure response that triggers the health check injection:
{
"posExtensions": {
"nodes": [
{
"location": { "id": "gid://shopify/Location/1", "name": "Downtown Store", "isActive": true },
"enabled": true,
"surfaces": ["ios", "android"],
"staffRoleAccess": [
{ "role": "sales_staff", "hasPermission": true },
{ "role": "store_manager", "hasPermission": true }
],
"lastConfiguredAt": "2026-07-01T10:00:00Z"
},
{
"location": { "id": "gid://shopify/Location/2", "name": "Airport Kiosk", "isActive": true },
"enabled": false,
"surfaces": [],
"staffRoleAccess": [
{ "role": "sales_staff", "hasPermission": false },
{ "role": "store_manager", "hasPermission": false }
],
"lastConfiguredAt": null
}
]
}
}
The health check detects that Airport Kiosk has never had the extension enabled — lastConfiguredAt: null — and injects a Sidekick task targeted at the store owner or manager with location-specific context:
{
"task_id": "pos-extension-location-gap",
"title": "POS extension not active at Airport Kiosk",
"description": "Your extension is live at Downtown Store but has never been enabled at Airport Kiosk. Staff there cannot access it.",
"surface": "pos",
"importance": "high",
"contributed_by": "app",
"visible_to_roles": ["owner", "store_manager"],
"hidden_from_roles": ["sales_staff", "fulfillment_staff", "marketing_staff"],
"deep_link": "/pos/locations/gid://shopify/Location/2/extensions"
}This closes the gap between initial setup and long-term operational health - not just “did the merchant finish onboarding?” but “is the configuration still correct today?”
Aside - Maybe add routines/schedule tasks that Sidekick can run, or maybe Shopify Flow can invoke into Sidekick, once the primitives are available, many creative ways will emerge.
3. Sidekick Hints Write API A structured interface for apps to register tasks with Sidekick, including explicit completion criteria tied to extension state:
{
"task_id": "string",
"title": "string",
"surface": "theme | checkout | customer_accounts | pos | flow",
"completion_criteria": { ... },
"importance": "critical | high | medium | low",
"contributed_by": "app | merchant | sidekick",
"callback_url": "https://t-app.com/webhooks/sidekick-completion"
}
4. A Vetted, Tri-Contributed Todo List
Sidekick already surfaces insights and suggested actions to merchants. But today this list is generic - it doesn’t reflect the specific operational state of a merchant’s business, and apps have no way to plug into it.
We’re proposing a structured, importance-ranked todo list where tasks are contributed by three parties and weighted accordingly:
Apps - Flags broken or incomplete extension state detected via health checks. Example - "Your checkout extension was removed from your live checkout profile"
Shopify / Sidekick - Flags platform-level issues, policy changes, or best-practice gaps. Example - “Your theme hasn’t been updated in 6 months - newer versions fix known performance issues”
Merchant - Adds their own priorities, goals, and context that affect how tasks are ranked. Example - “I’m launching a new product line next week” - elevates related tasks.
Importance is not static. A task’s priority in the list should be a function of:
The severity of the broken state (e.g., checkout extension missing = critical; block mispositioned = low)
The merchant’s current business context (e.g., a broken POS extension is more critical for a merchant with 80% in-store revenue)
Merchant-contributed signals (e.g., upcoming launch, seasonal peak, new staff onboarding)
Shopify’s understanding of the merchant’s plan, traffic, and growth stage based on a global dataset
This prevents the todo list from becoming noise. A task that’s critical for one merchant may be irrelevant for another - the ranking should reflect that.
5. Role-Mapped Task Visibility
Not every task should be visible to every staff member. A broken theme embed is irrelevant to a fulfillment staff member. A POS extension misconfiguration is irrelevant to a marketing manager.
Tasks in the Sidekick todo list should render based on the role and permissions of the logged-in staff member:
{
"task_id": "re-enable-embed-live-theme",
"title": "Your app embed was disabled on your live theme",
"required_permissions": ["theme_management"],
"visible_to_roles": ["owner", "developer", "store_manager"],
"hidden_from_roles": ["fulfillment_staff", "marketing_staff"]
}
Practical implications:
A store owner sees all tasks ranked by business impact
A developer/theme editor sees only theme, checkout, and extension tasks
A POS staff member sees only tasks relevant to their location and POS surface
A fulfillment manager sees only order, inventory, and shipping-related tasks
Tasks requiring permissions the logged-in staff member doesn’t have are hidden entirely - not shown as locked or disabled, just absent
This makes the todo list genuinely useful per session, not a wall of irrelevant noise that trains merchants to ignore it.
6. Verification Loop Behavior After guiding a merchant through a step, Sidekick queries the relevant state API, confirms success explicitly, and surfaces the specific failure reason if verification fails - rather than repeating the same instructions.
7. Completion Signals
Server-side:
sidekick/task_completedwebhook topic, fired when criteria are verified against live store stateClient-side:
sidekick:task_completedApp Bridge event, for real-time onboarding UI updates without a server round-trip
Aside - Whenever a task gets ignored by the system or marked as irrelevant by merchant in this framework, that can raise a webhook as well eg: sidekick/task_ignored_auto, sidekick/task_ignored_merchant
8. Persistent Task State Incomplete tasks survive session close and are re-surfaced the next time the merchant opens Sidekick - scoped to the app that registered them, dismissible by the merchant, re-assertable by the app if criteria remain unmet:
“Last time you were setting up [App Name]. Your app embed still isn’t enabled on your live theme. Want to finish that now?”
Health-check-injected tasks follow the same persistence model - they remain in the list until the state API confirms the issue is resolved, at which point they are automatically dismissed.
Why This Matters - For Every Party
For merchants: Setup is simple and consistent. Broken configurations are caught before any humans notice. The todo list shows what matters to them, not a generic checklist. Staff see only what’s relevant to their role - reducing noise and increasing action rates.
For app developers: A reliable signal replaces polling, redundant verification UIs, and support tickets. Health checks mean apps can detect and surface regressions, not just initial setup failures. Onboarding flows can gate on confirmed completion rather than assumed completion.
For Shopify: Sidekick becomes a core platform primitive to making the merchant ready with agentic AI-first ops expertise. App install-to-value time decreases. Merchants and the partner community spends less time on support broken or misconfigured extensions, instead focus on value-driving conversations. The todo list becomes a goto daily surface.
The Ask - In One Sentence
Give Sidekick the APIs to see what’s actually configured across extensibility areas, the structure to know what “done” looks like, a health check layer to catch when it breaks again, and a vetted role-aware todo list to surface what matters - to the right person, at the right time.
Final note: This case for Sidekick unlock for apps has been written with the help of Sidekick itself as part of a long conversation on getting merchants become AI-native in running their software stack. As these primitives and related APIs become available, value becomes the core part of any conversations merchants and partners have. Share your sidekick thoughts here or on the forum posts below.