Sidekick feedback

Hi folks,

Patrick here from Atlas Pickup Points and InPost – Tale Commerce apps, and I have Sidekick extensions running in both apps now. I’m genuinely excited about this surface - long term I think it will cut our support volume and help merchants set up our apps faster. Sharing observations from real usage, roughly by impact:

No way to open Sidekick from our embedded app. We’d love “ask Sidekick about this” buttons in our app. An App Bridge action to open the sidebar, ideally with a prefilled prompt, would let apps funnel questions into Sidekick instead of support tickets.

No access to extension/block installation state (big one). Our extensions can’t tell whether the merchant has added our app blocks (checkout, thank-you page, etc.). Inside our embedded app we have a setup guide that detects block placement and links to the right editor - we’d love Sidekick to share that same knowledge, but today our instructions have to say “Sidekick cannot tell whether a block is installed, do not guess” and redirect merchants back into the app. Read access to block/extension installation status would transform what Sidekick can do for setup support.

No usage observability. There are no analytics or invocation counts anywhere - not even in the Partner Dashboard. We built our own server-side logging, and we even added an intent input to every tool, asking Sidekick via instructions to summarize what the merchant is trying to accomplish, just to reconstruct context Shopify already has. A sanctioned intent/context field plus basic per-tool metrics would remove the need for every app to invent this.

No post-response lifecycle (waitUntil). The worker is torn down the instant a handler returns, so fire-and-forget telemetry silently fails - logging has to be an awaited request that adds latency to every tool call. Real consequence for us: some of our tools fetch straight from our CDN edge, and we left them completely unlogged because we weren’t willing to pay the latency of an awaited logging call.

Local dev doesn’t work. Testing requires shopify app deploy - there’s no dev preview, no way to invoke a tool with a chosen input, and no way to see whether your tool descriptions are winning the routing decision. Iterating on descriptions and instructions is deploy-and-pray.

App intermittently disappears from the Sidekick apps menu after deploy. Maybe 10% of shopify app deploy runs for us - the app just vanishes from the menu; a redeploy fixes it. Happy to share release id’s if useful.

app:// deep links stopped working. Sidekick still renders the link but clicking it does nothing. This affects all our app:// links (we use them to open a specific configuration and our Help page). I’m fairly sure they worked until recently.

No correlation identifiers. No conversation ID, so we can’t stitch multi-turn conversations together in our logs. And no deployed app/extension version, which would help correlate tool behavior with a release.

No user locale. Other extension surfaces provide it. We maintain our app UI in 8 languages - with the locale we could point merchants to documentation in their language and describe our UI in their terms.

One last note: we only expose queries, no mutations. Sidekick actions require fitting one of the predefined action templates, and none of them fit our apps write operations, which are purely app configuration. Support for app-defined actions would let us go further than read-only.

Thanks for the great work on this - happy to provide more detail on any of these.

+1 on the opening Sidekick from our app.

+1 on this. I came here to write this and I saw Patricks’ post.

Would be gamechanger if we can have our embedded app open Sidekick, as I believe right now, only a small percentage of our merchants utilize it.

We’re building on the Sidekick extension and automating more of our app’s analytics views + create operations.

And yes, being able to pass a query!

+1 for basically everything and specially:

Blockquote
One last note: we only expose queries, no mutations. Sidekick actions require fitting one of the predefined action templates, and none of them fit our apps write operations, which are purely app configuration. Support for app-defined actions would let us go further than read-only.One last note: we only expose queries, no mutations. Sidekick actions require fitting one of the predefined action templates, and none of them fit our apps write operations, which are purely app configuration. Support for app-defined actions would let us go further than read-only.

The pre-set actions types create friction for which I’m not entirely sure why is there, if we could create custom action types we could expose Sidekick to many of our app’s functionalities.

Thanks for taking the time to put together this feedback! I’ve forwarded everything mentioned here to the relevant team.

Opening sidekick from within the app and inserting a relevant query is a must. Plus some relevant lifecycle hooks on how the query executed in sidekick as well.

Hi @Patrick_Jakubik hope that u are doing well, may I ask you a question about the 1-second response time requirement when building a Shopify Sidekick App Extension. How do you handle or work around this limit? Whenever you have some time, I’d really appreciate your help. Thank you!

Following up on a few items, could you share:

  • For the app:// links: the exact steps needed to reproduce the issue.
  • For the app disappearing after deployment: does it return after a short wait and page refresh?
  • For app-defined actions: could you share examples of the app-specific configuration actions you’d like to define and expose through Sidekick? If a reusable intent type would fit, you can propose one through the Sidekick app extensions intent-types repository.

I’ve followed up privately for the reproduction specifics.