Sidekick Has Zero Visibility into POS Extension Setup - Sidekick's feedback about it's own limitations

Extensions
1

Disclaimer - I didn’t write this, sidekick generated it based on the context it has wrto POS extensibility. (with emdashes removed). Context and direction is mine, notes are from sidekick on what can be done with examples.

POS UI extensions are configured entirely within the POS app - a surface Sidekick currently has no presence in. This makes POS the hardest extension type to verify and the most likely to be misconfigured, especially for less technical merchants running physical retail.

Specific Gaps

Enablement

  • Is the POS extension enabled at all?
  • Is it enabled on the correct location(s) - or only on one of several retail locations?
  • Is it active on both iPad and mobile POS surfaces?

Permissions

  • Do staff roles have the correct permissions to see and interact with the extension?
  • Was the extension accidentally restricted to owner-only access?

Configuration

  • Were any required settings (e.g., custom fields, linked products, payment methods) configured within the POS extension itself?
  • Did a POS app update reset any of these settings?

Verification

  • There is currently no admin-side API or Sidekick capability to confirm any of the above without physically checking the POS device, ie the changes may or may not have cascaded to every device without physical checks

What We’re Asking For

    1. POS extension state via Admin GraphQL - introduce a posExtensions query that returns per-location enablement status, active surface (iOS/Android), and last configuration timestamp, filterable by app ID:
    query {
  posExtensions(appId: "your-app-id") {
    location {
      id
      name
    }
    enabled
    surfaces
    lastConfiguredAt
  }
}
    1. Staff role permission audit query - expose which staff roles have access to a given POS extension, so Sidekick can flag misconfigurations without requiring the merchant to open the POS app
    2. Sidekick hints write API - surface-specific criteria for POS:
    {
  "task_id": "enable-pos-extension-all-locations",
  "surface": "pos",
  "completion_criteria": {
    "type": "pos_extension_enabled",
    "scope": "all_locations",
    "extension_handle": "your-extension-handle",
    "app_id": "your-app-id"
  },
  "callback_url": "https://your-app.com/webhooks/sidekick-completion"
}
    1. sidekick/task_completed webhook - payload includes per-location enablement confirmation, surfaces active, and staff role coverage status
    2. Sidekick deep link into POS configuration - from the web admin, Sidekick should be able to navigate the merchant directly to the POS extension settings page for a specific location, rather than requiring them to find it manually in the POS app

Why It Matters

POS merchants are often the least technical segment of Shopify’s merchant base. They rely on setup “just working.” A POS extension that’s enabled at one location but not another, or visible to owners but not staff, creates real operational failures at the point of sale. Sidekick - with the right APIs - is the ideal guided setup layer for this audience.

2

Hey @Aravind_Baskaran - thanks for putting this together. The overall limitation is fair: for sure. Right now, Sidekick doesn’t currently have a generic way to verify every part of POS UI extension setup across Admin, POS devices, and app-owned configuration.

One thing I just wanted to mention is that POS configuration is no longer entirely device-side. Extensions and Smart Grid layouts can now be managed through the Admin POS editor, with deep-linking support: Deep linking into Shopify POS editor

There also isn’t one universal “enabled” state. App installation, extension targets, Smart Grid placement, POS permissions, and settings stored by the app or device are separate, which makes a generic location/device/staff-role audit a little more complex.

We’re continuing to expand both the POS editor and Sidekick app extensions, including ways apps can expose relevant data and safe actions: Sidekick app extensions. I can’t confirm a specific roadmap or timeline for the proposed audit APIs or webhook flow though.

Could you share one or two concrete merchant workflows where this would help most? Like, verifying layout/location placement, staff access, an app-specific setting, or having Sidekick help change the setup? That’ll help clarify which platform layer is missing. I can definitely pass this on as a feature request!

3

Thanks again @Alan_G for the ack! Like the theme one, there are two parts here

  1. POS extension state API
  2. Sidekick tasks/completion primitives

Where it will help with state as of today

  1. Is a POS extension enabled at a location?
    1. If yes, at what position/page?
    2. When was it first enabled?
    3. When was it refreshed? ie what version is the extension running at a location?
    4. Status - No support. We built a set of “heartbeat” primitives to identify “enabled” and a lack of heartbeats over x days as “disabled”, along with version info in every call to determine which locations/devices are outdated. This also means low confidence to inform merchants if they still need to enable/perform an action
  2. What physical integrations does that POS location/device have enabled? ie barcode scanner? or printer?
    1. The staff experience using the extension will vary significantly based on this info
    2. Status - No support
  3. Staff Role x Extension functionality - POS API to know the pinned staff’s roles and render different messaging on the tile, instead of showing “error” state.
    1. Status - No support, ie staff information can be retrieved, but it doesn’t make sense to handle roles depth per tile, can be configured in the extension toml instead.

On Sidekick tasks/completion primitives, I have tried to organize the context of all the asks between this and other extensibilities like theme one over here - please let me know if those make sense in this context or requires a new forum post? Hope this context helps in taking this forward?

4

Hey @Aravind_Baskaran - thanks, this extra context helps a lot.

The heartbeat workaround makes sense since a missing heartbeat can’t reliably distinguish a disabled or unpinned extension from a location that simply hasn’t used it recently. The per-location placement and version state, supported physical integrations, and staff-role context are all useful concrete examples.

I’ve sent the POS extension state request along as a separate feature request. I’ve also passed along the broader Sidekick task and completion primitives request that overlaps with your theme thread, so just wanted to confirm.

I can’t confirm a roadmap or timeline, but we’ve got enough context here now. I’m going to mark the thread as solved for tracking, but let me know if I can help out further.