Intermittent application_cant_be_loaded_misconfigured on app load — request never reaches our server

Authentication & Access
1

Intermittent application_cant_be_loaded_misconfigured on app load — request never reaches our server

App details

  • App: SuperSMS AI SMS
  • client_id: e9b5fd17abdbcfbe1413f8cd2bb2e5d9
  • Type: Public app, non-embedded (embedded = false)
  • Installation: Shopify managed installation (use_legacy_install_flow = false)
  • App URL: ``https://api.supersms.ai/auth``
  • Redirect URL: ``https://api.supersms.ai/auth/callback``
  • Scopes (10):
    • read_orders
    • write_orders
    • read_products
    • read_customers
    • write_customers
    • read_draft_orders
    • read_script_tags
    • write_script_tags
    • write_price_rules
    • write_discounts

Symptom

When a merchant opens the app (or installs it via the managed install link), the browser is intermittently redirected to:

https://admin.shopify.com/store/{shop}/apps?oauth_error=application_cant_be_loaded_misconfigured

instead of the app being loaded.

Frequency: roughly 1 in 4–6 attempts.

It is not tied to a specific shop or browser. We can reproduce the issue on the same store simply by repeating the same action.

Key observation — our server never sees the request

We log every request, including path and query parameters.

When the error occurs, no request arrives at our App URL at all. The server log is completely empty for that attempt.

Example:

Attempt 1 → GET /auth?hmac=...&host=...&timestamp=...&shop=... → 200/302 ✓ app loads
Attempt 2 → GET /auth?hmac=...&host=...&timestamp=...&shop=... → 200/302 ✓ app loads
Attempt 3 → GET /auth?hmac=...&host=...&timestamp=...&shop=... → 200/302 ✓ app loads
Attempt 4 → (no request logged) → ✗ oauth_error=application_cant_be_loaded_misconfigured
Attempt 5 → GET /auth?hmac=...&host=...&timestamp=...&shop=... → 200/302 ✓ app loads

Additional observations:

  • Our /health endpoint returns 200 continuously during all attempts.
  • Our TLS certificate is valid.
  • The domain resolves correctly.
  • The App URL is reachable immediately before and immediately after the failing attempt.

This suggests that Shopify is aborting the app load before requesting our application_url, rather than our endpoint failing to respond.

What we already checked and ruled out

  1. App URL reachable / TLS valid
    Result: ✓ 200 before and after every failure

  2. application_url matches a registered redirect host
    Result: ✓ Same host: api.supersms.ai

  3. Scopes match between app configuration and shopify.app.toml
    Result: ✓ 10 scopes, identical

  4. HMAC signature on managed-install requests
    Result: ✓ Present and valid on every request we receive

  5. Stored access/refresh tokens for the shop
    Result: ✓ Active, valid refresh token

  6. Server logs during failure
    Result: ✗ No request received

  7. Reproduced with a second app version
    Result: ✓ Same behaviour

What we changed on our side

We previously started a new OAuth authorization round trip on every load of /auth, including when the app was already installed.

We have since changed /auth so that:

  • An already-installed shop is given a session directly.
  • OAuth is only started when the app is genuinely not installed.

This removed one class of failures, but the intermittent error described above still occurs.

Importantly, the failure still happens without any request reaching our server.

Related report

This looks very similar to the issue described in the following Shopify Community thread, including the roughly 1-in-5-to-10-attempt frequency and the redirect to:

?oauth_error=application_cant_be_loaded_misconfigured

Questions

  1. Is this a known issue with Shopify managed installation for non-embedded apps?

The linked report appears to describe the same behaviour.

  1. Is there anything in the app configuration that could cause Shopify to abort the load before requesting application_url?

  2. Is there a way for us to see why Shopify rejected the load on those attempts?

For example:

  • Partner Dashboard logs
  • An error detail behind oauth_error
  • A request ID / correlation ID that we can quote when contacting Shopify Support
  • Any other Shopify-side diagnostic information
  1. Would switching use_legacy_install_flow to true be supported for an existing public app?

If supported, would switching to the legacy install flow avoid this condition?

Any guidance would be appreciated.

We can provide:

  • Full request logs
  • A screen recording showing the failure
  • A test store
  • Timestamps for successful and failed attempts
  • Any additional technical information needed to reproduce the issue.
2

Hi @PENGUIN_SECRET_AGENC, thanks for all the details! I had a look for you and nothing I can point to confirms a known managed-installation issue for non-embedded apps, and nothing in the checks you’ve already run (scope match, redirect and app URL host alignment, reachability) points to a specific misconfiguration on your side either.

If the app gets opened several times in quick succession, the install flow can treat that as a redirect loop and abort, so how the app was opened on a failing attempt would be good to know - whether this happens on Open app, the install link, or both, and how the app was opened that time (fresh navigation, quick retry, refresh, multiple tabs, or browser preloading).

There is no self-serve way to see the cause of the error, but to help us trace a failed attempt on our side, share the x-request-id header from the failing redirect response (your browser’s dev tools Network tab will show it).

For use_legacy_install_flow, the documentation still supports it but doesn’t recommend it, and I can’t promise switching resolves this. Your app authenticating through the authorization code grant as a standalone app is expected, so no change is needed there.