Customer Account UI extension static target not invoked for embedded app, works for extension-only app on same dev shop

Hi,

I’m building a Shopify app that needs to render a Customer Account UI extension on the Order Status page.
Both block target (customer-account.order-status.block.render) and static target
(customer-account.order-status.payment-details.render-after) fail to render for my embedded app
with backend, even though the bundle is loaded (200 OK from extensions.shopifycdn.com).

As a control, I created a minimal extension-only app with the same static target, deployed and installed
on the same fresh dev shop. The minimal app’s banner renders correctly.

I did A/B audit by progressively adding my app’s config differences to the minimal app (metafields, scopes,
mandatory webhooks, orders/* webhooks with PCD approval, app_proxy, network_access, additional block targets).
None of these additions caused the minimal banner to stop rendering.

Only remaining differences between the two apps:

  • application_url (real backend vs default app home)
  • AppDistribution explicit vs default
  • Backend webhook routing (real vs 404)

Has anyone seen a similar pattern? Is there a known issue where embedded apps with real backends fail to
trigger Customer Account UI extension host invoke?

API version: 2026-04. JSX preact (verified bundle inspection: no react/jsx-runtime). Custom distribution.
Fresh dev shop, clean install. Tested with customer authentication.

Thanks!

Hey @support_uniple - appreciate the nicely controlled A/B; that narrows it a lot.

A few things to verify before we call this a platform issue, because the symptom you’re describing (bundle 200s from CDN but target never invokes, embedded-only) usually traces back to one of these:

1. The deployed version vs the installed version

Customer Account UI extensions render the deployed and released version, not whatever’s in your local source. Two checks:

  • Run shopify app deploy for the embedded app and confirm the new version is released (not just deployed) in the Partner Dashboard → your app → Versions.
  • Confirm the installed instance on the dev shop is on the released version. Reinstall if in doubt — embedded apps with version-pinned installs can lag.

The extension-only app likely auto-releases on deploy, which would explain the divergence even with identical TOML.

2. App distribution + access scope handshake

You called out AppDistribution is explicit on the embedded app. If that’s set to app_store while the dev shop install predates required configuration (e.g. for protected customer data approval, network_access review status, or any “must be approved” capability), the extension can be quietly disabled at runtime — bundle fetches but the host never invokes the target. Check Partner Dashboard → App setup → Protected customer data access status and Distribution state.

3. The static target’s host feature has to be present

customer-account.order-status.payment-details.render-after only fires when the payment-details section actually renders on that order. If the order has no captured payment, is free, uses certain deferred-payment flows, or is in a state where Shopify doesn’t render payment details, the static target is skipped — by design (static targets docs). The block target (customer-account.order-status.block.render) also requires the merchant to have placed your block via the checkout & accounts editor — until they do, it won’t render. Worth double-checking both.

4. Quick diagnostic

Swap in customer-account.order-status.block.render without placing it in the editor and instead try customer-account.order-index.block.render or customer-account.profile.block.render and put a <Banner>Hello</Banner> in it. If those don’t fire either on the embedded app but do on the extension-only app, that’s a strong signal it’s an app-level config issue, not target-specific.

If you’ve checked all of the above and you can still reproduce extension-only working / embedded failing on the same shop, that’s worth filing — happy to escalate. Drop your two app handles (or partner org + app IDs in DM if you’d rather) and I’ll have a look.

I did find a related GitHub issue too: Shopify/cli#5988 that covers a similar “extension doesn’t render in preview” pattern, though it’s CLI-side rather than installed-app-side.

Verification results — strong app-level config issue signal confirmed:

Hypothesis 1 (released vs deployed): REJECTED

  • uniple checkout app v27 confirmed “Released” status in Partner Dashboard Versions tab.

Hypothesis 2 (app config handshake): STRONGLY INDICATED

  • PCD = Draft status for BOTH apps (uniple + minimal), so PCD Draft alone doesn’t explain the asymmetry.
  • Network access in checkout/account UI extensions = Granted for both.

Hypothesis 3 (static target host feature): Less likely; minimal app’s static target renders on the paid Manual Payment order page.

Hypothesis 4 (different targets): CONFIRMED app-level issue

  • Added customer-account.order-index.block.render + customer-account.profile.block.render to BOTH apps with simple critical banners (no editor placement).
  • On the same fresh dev shop, same authenticated customer:
    • On /account/orders (orders list page): minimal app banner RENDERS, uniple checkout app banner does NOT RENDER.
    • On /account/orders/ (order-status page): same pattern (minimal renders, uniple doesn’t).
    • Profile page banners require editor placement, so unrelated.

This rules out target-specificity; the embedded uniple checkout app’s customer-account UI extensions are silently disabled across multiple targets on the same shop where the minimal extension-only app works.

Please escalate via internal logs:

  • Embedded (failing): uniple checkout, client_id: cdf36943d96d6284bdfa212ee9801b45
  • Extension-only (working): uniple-min-ca-diag, client_id: c7c56953953d5f52671b5a3d0c72cda3
  • Partner org: uniple inc., Partner ID: 218108954
  • Test shop installed both: uniple-fresh-diag-20260525.myshopify.com

Thank you very much for the verification framework — it definitively narrowed the cause to app-level config.