303 response on checkout creation but no location in header?

Shopify Partner
5 0 0


I'm currently playing around with this guide on my site:

It says that sometimes under huge sales the checkout creation request might return 303 with a location in the headers, while I have been testing this, even though I get the 303 response status code it doesn't contain any header location to start polling from? 

Why is this?


Shopify Staff
Shopify Staff
618 45 84

Hi @Gelingitendo,


I've never encountered this behaviour before. If you're getting a 303 there should be a location header available in your response. Are you logging the full response?


If possible, can you share the response you got here so I can investigate? You might need to redact any sensitive information before you do so. Also, if you have direct messaging enabled on our community, you can DM me it.



New Member
1 0 0

I'm also having this issue.  Here's my request:


curl -i -X POST \
  https://****.myshopify.com/admin/checkouts.json \
  -H 'Content-Type: application/json' \
  -H 'X-Shopify-Access-Token: ****' \
  -d '{
    "checkout": {
        "email": "email@example.com"

Most of the time I get a 201 or 202 response with a location header and a body that returns the {'checkout': ... } data.  However, after sending the request approx 10 times in 10 seconds eventually I get this:


HTTP/2 303 
date: Wed, 14 Aug 2019 19:07:38 GMT
content-type: application/json; charset=utf-8
set-cookie: __cfduid=****; expires=Thu, 13-Aug-20 19:07:37 GMT; path=/; domain=.myshopify.com; HttpOnly
x-sorting-hat-podid: 50
x-sorting-hat-shopid: ****
referrer-policy: origin-when-cross-origin
x-frame-options: DENY
x-shopid: ****
x-shardid: 50
x-stats-apiclientid: ****
x-stats-apipermissionid: ****
x-shopify-api-version: 2019-04
strict-transport-security: max-age=7889238
x-request-id: 04d49833-4d93-4206-8306-13903a044f3a
x-shopify-stage: production
content-security-policy: default-src 'self' data: blob: 'unsafe-inline' 'unsafe-eval' https://* shopify-pos://*; block-all-mixed-content; child-src 'self' https://* shopify-pos://*; connect-src 'self' wss://* https://*; frame-ancestors 'none'; img-src 'self' data: blob: https:; script-src https://cdn.shopify.com https://checkout.shopifycs.com https://js-agent.newrelic.com https://bam.nr-data.net https://dme0ih8comzn4.cloudfront.net https://api.stripe.com https://mpsnare.iesnare.com https://appcenter.intuit.com https://www.paypal.com https://js.braintreegateway.com https://c.paypal.com https://maps.googleapis.com https://www.google-analytics.com https://v.shopify.com https://widget.intercom.io https://js.intercomcdn.com 'self' 'unsafe-inline' 'unsafe-eval'; upgrade-insecure-requests; report-uri /csp-report?source%5Baction%5D=create&source%5Bapp%5D=Shopify&source%5Bcontroller%5D=admin%2Fabandoned_checkouts&source%5Bsection%5D=admin_api&source%5Buuid%5D=04d49833-4d93-4206-8306-13903a044f3a
x-content-type-options: nosniff
x-download-options: noopen
x-permitted-cross-domain-policies: none
x-xss-protection: 1; mode=block; report=/xss-report?source%5Baction%5D=create&source%5Bapp%5D=Shopify&source%5Bcontroller%5D=admin%2Fabandoned_checkouts&source%5Bsection%5D=admin_api&source%5Buuid%5D=04d49833-4d93-4206-8306-13903a044f3a
x-dc: gcp-us-east1,gcp-us-east1
nel: {"report_to":"network-errors","max_age":2592000,"failure_fraction":0.01,"success_fraction":0.0001}
report-to: {"group":"network-errors","max_age":2592000,"endpoints":[{"url":"https://monorail-edge.shopifycloud.com/v1/reports/nel/20190325/shopify"}]}
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 5065367a6ef4791c-LAX


Lots of headers and an empty {} response body, but no location header.


Per documentation, I should be getting a location header for 303 responses:

Shopify Staff
Shopify Staff
618 45 84

Hey folks,


I was able to replicate this behaviour and have filed an issue internally. I'll post back here once there's a resolution.



6 1 0

Did you ever find a resolution?

Shopify Staff
Shopify Staff
618 45 84


Hi @JeromeJaJa,


Since the issue is that we're returning a 303 status without a location header when in reality, this is a throttle being hit, we are looking at changing the status returned when creating 5 checkouts with the same payload in succession. It will likely be changed to a 429, but this change has not been prioritized yet. I'm continuing to track the issue and will post back here with an update. The easy way around this is to simply not create many checkouts in succession with the same payload.