We’re seeing intermittent 431 errors (“This page isn’t working”) on two different flows, both of which go through a redirect from the old store-name.myshopify.com/admin/... URL format to the newer admin.shopify.com/store/store-name/... format:
Billing confirmation links. When we generate a confirm_recurring_application_charge URL for RecurringApplicationCharge, it comes back in the old format:
Shopify redirects this to the new admin domain, and that redirect sometimes 431s.
App install flow. Clicking “Install” from the Shopify App Store also routes through the old /admin/oauth/redirect_to_install/... format before redirecting, and we’ve seen the same 431 there. Screenshot attached from that flow (checkouttestprod.myshopify.com/admin/oauth/redirect_to_install/``...).
A few things we’ve observed while trying to isolate it:
It’s not browser-specific — we’ve reproduced it on Chrome, Safari, and Brave.
It’s intermittent in onset, but once it starts happening on a given store/browser combo, it stays consistent for a while rather than resolving randomly.
Our main concern is that we have no way to verify whether merchants installing our app are hitting this too — we can only reproduce it in our own testing, and we have no visibility into install-flow failures on the merchant side. If this is happening during real installs, it would silently break onboarding for those merchants without us ever knowing.
Is anyone else seeing this on the billing confirmation or install redirect flows specifically? And is this a known issue on Shopify’s side related to the admin domain migration — is anyone from Shopify able to confirm whether it’s being tracked?
Hey @romie and @advplyr - thanks for bringing this to our attention.
We’ve seen a few isolated examples of similar 431 responses on these redirect flows, but it’s hard to say what’s happening without a concrete example.
If you can reproduce this again, could you share the x-request-id from the failed response? If that isn’t available, a shop ID and approximate timestamp, including the timezone, may help us identify the request. If you’d prefer not to share the shop ID publicly, let me know and I’m happy to set up a DM.
Hey, I am still able to reproduce this consistently on my developer store quickstart-52461e3c (Shop ID 61225500716). I have just done a few tests now. Sun, 30 Aug 2026 15:29:16 GMT
I don’t have x-request-id because the subscription is created server side. This is the most recent subscription ID for that shop: gid://shopify/AppSubscription/28158296108
Hey @advplyr - thanks for sharing the timestamp and app subscription ID.
Those details helped me locate the affected requests in our logs, and I’m looking into this further on our end. I’ll follow up here when I have more information to share.
Just had a merchant reporting this problem to us as well. Asked the merchant to clear cookies, login to Shopigy again and retry. That worked, but obviously isn’t a solution. Wondering how many sales we are missing because of this. We do one-time payments only and the percentage of merchants completing the payment process is down a lot (from ~76% to less than 50%).
Hey folks - thanks for the additional reports. I recognize this is getting in the way of app installs and billing approvals for affected developers and merchants. This is still on our radar, but we don’t have a confirmed fix or timeline to share yet.
As mentioned in the thread, clearing cookies and signing back in helped one affected merchant, though I completely understand it isn’t an ideal workaround. I’ll follow up here as soon as I have more to share.
