Hello everyone,
since today, our billing flow suddenly broke in production (while it still works fine in development).
When selecting a plan, the POST request to billing.data returns a 400 Bad Request.
The only response body we receive is:
[{ "_1": 2 }, "error", ["SanitizedError", 3, 4, -7], "Error", "Unexpected Server Error"]
We don’t get any additional details from the server logs.
If this error message rings a bell for anyone or you’ve seen something similar before, any help would be greatly appreciated.
Thanks!
Hey @benjamin_bailly! This looks like something going wrong on the platform side rather than in your app code and I’ll be happy to take a look.
Can you grab the x-request-id header from one of the failed responses? That would let us trace the request in our logs and raise it with the relevant team.
Hi, thanks for helping. Here are the details:
RequestId (EDIT): 3c2205b3-9101-44cd-b317-a7e30290612c
Endpoint: POST /app/billing.data
Observed response body: [{“_1”:2},“error”,[“SanitizedError”,3,4,-7],“Error”,“Unexpected Server Error”]
HTTP status: 400
I can also provide x-amzn-requestid and x-amz-cf-id values from the client responses if useful.
I checked the request ID you shared and it doesn’t return any logs on our end. That, along with the x-amzn-requestid and x-amz-cf-id headers you mentioned, suggests the 400 response is coming from your own app server rather than from Shopify directly.
If you’re able to check your server-side logs for the actual error behind that request, there’s likely an underlying exception from the Shopify billing API call that would tell us more. If you can share that error (and ideally a Shopify x-request-id from the failing API call, which follows a UUID-TIMESTAMP format), I can trace it on our end.
On our server we only have the following logs for the failing request:
Error: Bad Request
2026-02-06T10:41:59.892Z
at singleFetchAction (react-router/dist/development/chunk-4LKRSAEJ.mjs:847:31)
at handleSingleFetchRequest (react-router/dist/development/chunk-4LKRSAEJ.mjs:1378:51)
at requestHandler (react-router/dist/development/chunk-4LKRSAEJ.mjs:1221:24)
at requestHandler (react-router/dist/development/chunk-4LKRSAEJ.mjs:1330:12)
at @react-router/express/dist/index.mjs:28:28
at processTicksAndRejections (node:internal/process/task_queues:105:5)
POST /app/billing.data → 400 Bad Request
RequestId: 3c2205b3-9101-44cd-b317-a7e30290612c
Timestamp: 2026-02-06T10:41:59.894Z
The response body we receive from billing.data is in the google console:
[{"_1":2},"error",["SanitizedError",3,4,-7],"Error","Unexpected Server Error"]
The only request id I have is the one above: 3c2205b3-9101-44cd-b317-a7e30290612c.
Thanks for the logs! The stack trace is from React Router’s single-fetch internals (singleFetchAction / handleSingleFetchRequest), and the “Bad Request” appears to be thrown at the framework level before we get a Shopify request ID, so we still can’t trace anything on our end.
To isolate whether the Shopify billing API itself is the issue, can you try calling the appSubscriptionCreate mutation directly via cURL/Postman/Insomnia against one of the affected production stores? That would tell us whether the billing API is returning an error, and if it does, the response will include a Shopify x-request-id header I can look up.
If the direct call works, the issue is in the framework/middleware layer between your app and the API.
It seems to work when calling the API directly via Insomnia.
Testing is a bit tricky since the issue only happens in production.
I’ll take a closer look on the React Router side.
Here is the x-request-id from the direct billing API call if it helps (from the api calls that works):
b8c91084-a9cb-42fe-b52c-ee96e0453e35-1770390214
I up this topic, still on the same issue ,
Hey @benjamin_bailly thanks for following up, sorry to hear the issue persists. I traced the Insomnia request ID you shared (b8c91084-a9cb-42fe-b52c-ee96e0453e35-1770390214) through our logs and it’s clean across the board. The appSubscriptionCreate mutation returned a 200 with no errors on our side. The billing API is working correctly for your app and store.
My main finding is that the failing production requests never reach Shopify at all. The request ID from the failing call has no matching logs on our end, which suggests the 400 is being generated within your app before the Shopify API call is made.
At this point I’d suggest adding logging around the actual appSubscriptionCreate call in your production billing route to capture the Shopify x-request-id response header (format: UUID-TIMESTAMP). If you’re able to capture one from a failing request, I can trace it in our logs.
If no Shopify request ID is present, that confirms the request isn’t making it to us and the issue is between your route handler and the API call.
1 Like