fix(shopify): request expiring offline tokens for OAuth2 (INT-1985)

@surajmarkupdraftchecks n/achecks…fix/shopify-expiring-tokens-int-1985 → master1 files · +1 −1updated 1mo ago

▸Description · 1 noise

Description

Shopify deprecated non-expiring offline tokens for public apps created on/after 2026-04-01 (changelog). Composio's Shopify OAuth2 flow currently does not pass expiring=1 on the token-exchange POST, so Shopify defaults to handing us a non-expiring offline token. Every subsequent Admin API call against that token returns:

HTTP 403
{"errors":"[API] Non-expiring access tokens are no longer accepted for the Admin API. Start using expiring offline tokens: https://shopify.dev/docs/apps/build/authentication-authorization/access-tokens/offline-access-tokens#expiring-vs-non-expiring-offline-tokens"}

This PR makes two changes to the OAUTH2 auth scheme in apps/shopify/config.ts:

Drop authorization_params: { access_mode: 'per-user' }. Per-user / online tokens are 24h, interactive-staff-user-bound, and designed for embedded admin UIs. Composio is a backend tool-execution platform — offline (per-shop) is the correct shape for our use case.
Add token_params: { expiring: '1' }. Sends expiring=1 on the body of POST /admin/oauth/access_token, opting into Shopify's expiring offline tokens. The response now includes refresh_token, expires_in (~3600s), and refresh_token_expires_in (~7776000s = 90d) — all of which Apollo's existing OAuth2 connection schema (Oauth2ActiveConnectionDataSchema) already persists automatically.

How did I test this PR

Code-traced the flow end-to-end: oAuth2.ts:687 callback → oAuth2.ts:760-786 token-exchange POST → oAuth2.ts:783-786 response parsing via Oauth2ActiveConnectionDataSchema.safeParse → handleOAuthCallback.ts:362-378 connection persistence. Confirmed the schema already accepts refresh_token (connectionDataScheme.ts:157) and expires_in (connectionDataScheme.ts:159) fields.
Validated against Shopify's offline access tokens docs — expiring=1 is the documented body parameter.
End-to-end smoke test against a real Shopify Partner dev store with a post-2026-04-01 public app — pending (will run before promoting from Draft to Ready). Verifies: fresh install returns expiring token + refresh_token, post-1h refresh succeeds, Admin API calls succeed.

Customer evidence

Plain ticket: T-10568
Failing log: log_nQces4HF8BnB (SHOPIFY_GET_SHOP_DETAILS, 2026-04-28 16:07:07 UTC) returning 403 with the verbatim Shopify error
Affected store: kanbanify-dev-2025-11-24.myshopify.com (empla)
Affected connections: ca_gYhcU6FPcuxW, ca_udW4_DdBvI3z, ca_wqxxJMj-mjag, ca_CqfkWLiP6LhX

Linear: INT-1985 (this PR), parent PLEN-2132 (umbrella for Shopify admin-token deprecation)
Sister PR: #22465 (S2S_OAUTH2 scheme for Dev Dashboard apps, merged 2026-04-29) — closed the S2S half of PLEN-2132
Companion Hermes PR: strips redirect_uri from Shopify refresh body (defensive, 1-line)
Backfill admin endpoint to migrate existing broken connections via Shopify's token-exchange grant — separate PR, tracked on INT-1985 acceptance criteria

🤖 Generated with Claude Code

▸ 1 bot/status comment hidden

@linear[bot]1mo ago

Problem: Our Shopify OAuth handler calls POST https://{shop}.myshopify.com/admin/oauth/access_token (auth-code-grant exchange) without the expiring=1 parameter. Shopify defaults expiring to 0 (non-expiring). As of April 1, 2026, Shopify rejects non-expiring tokens for all public apps created on or after that date with a 403: "Non-expiring access tokens are no longer accepted for the Admin API. Start using expiring offline tokens."

Custom apps (single-store) are exempt, so existing customers are unaffected. But any customer with a public Shopify app created post-April-1 (like empla.io) gets 403 on every Admin API call.

Customer impact:

Customer: empla.io (du@empla.io), Project: pr_5bIFbQiiLsoh
Failing connected accounts: ca_gYhcU6FPcuxW, ca_udW4_DdBvI3z, ca_wqxxJMj-mjag, ca_CqfkWLiP6LhX
Support ticket: T-10568

Root cause (confirmed):

mercury/apps/shopify/config.ts — OAuth2 scheme has authorization_params: { access_mode: 'per-user' } which forces online tokens (~24h expiry, no refresh token)
hermes/apps/apollo/src/lib/connected_accounts/oAuth2.ts:537-579 — token exchange body does NOT include expiring=1
No token_params or refresh_params defined in Shopify config
Apollo's refresh handler at refreshAccessToken.ts:794-810 skips Shopify because no refresh_token exists

Fix needed:

Add expiring=1 to the token exchange request body (via token_params in Mercury config or Apollo code)
Switch from per-user (online) to offline access mode to get refresh tokens from Shopify
Implement refresh token handling for Shopify's + + fields

loading diff…

Description

HTTP 403 {"errors":"[API] Non-expiring access tokens are no longer accepted for the Admin API. Start using expiring offline tokens: https://shopify.dev/docs/apps/build/authentication-authorization/access-tokens/offline-access-tokens#expiring-vs-non-expiring-offline-tokens"}

This PR makes two changes to the OAUTH2 auth scheme in apps/shopify/config.ts:

Drop authorization_params: { access_mode: 'per-user' }. Per-user / online tokens are 24h, interactive-staff-user-bound, and designed for embedded admin UIs. Composio is a backend tool-execution platform — offline (per-shop) is the correct shape for our use case.

Add token_params: { expiring: '1' }. Sends expiring=1 on the body of POST /admin/oauth/access_token, opting into Shopify's expiring offline tokens. The response now includes refresh_token, expires_in (~3600s), and refresh_token_expires_in (~7776000s = 90d) — all of which Apollo's existing OAuth2 connection schema (Oauth2ActiveConnectionDataSchema) already persists automatically.

How did I test this PR

Code-traced the flow end-to-end: oAuth2.ts:687 callback → oAuth2.ts:760-786 token-exchange POST → oAuth2.ts:783-786 response parsing via Oauth2ActiveConnectionDataSchema.safeParse → handleOAuthCallback.ts:362-378 connection persistence. Confirmed the schema already accepts refresh_token (connectionDataScheme.ts:157) and expires_in (connectionDataScheme.ts:159) fields.

Validated against Shopify's offline access tokens docs — expiring=1 is the documented body parameter.

End-to-end smoke test against a real Shopify Partner dev store with a post-2026-04-01 public app — pending (will run before promoting from Draft to Ready). Verifies: fresh install returns expiring token + refresh_token, post-1h refresh succeeds, Admin API calls succeed.

Customer evidence

Plain ticket: T-10568

Failing log: log_nQces4HF8BnB (SHOPIFY_GET_SHOP_DETAILS, 2026-04-28 16:07:07 UTC) returning 403 with the verbatim Shopify error

Affected store: kanbanify-dev-2025-11-24.myshopify.com (empla)

Affected connections: ca_gYhcU6FPcuxW, ca_udW4_DdBvI3z, ca_wqxxJMj-mjag, ca_CqfkWLiP6LhX

Linear: INT-1985 (this PR), parent PLEN-2132 (umbrella for Shopify admin-token deprecation)

Sister PR: #22465 (S2S_OAUTH2 scheme for Dev Dashboard apps, merged 2026-04-29) — closed the S2S half of PLEN-2132

Companion Hermes PR: strips redirect_uri from Shopify refresh body (defensive, 1-line)

Backfill admin endpoint to migrate existing broken connections via Shopify's token-exchange grant — separate PR, tracked on INT-1985 acceptance criteria

🤖 Generated with Claude Code

fix(shopify): request expiring offline tokens for OAuth2 (INT-1985)

Description

How did I test this PR

Customer evidence

Related

Description

How did I test this PR

Customer evidence

Related