303 response on checkout creation but no location in header?

Retired Boards Appdev Custom Storefronts
1

Hello,

I’m currently playing around with this guide on my site:
https://help.shopify.com/en/api/guides/sell-through-the-checkout-api

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?

Thanks!

2

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.

Cheers,

3

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-userid: 
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:

4

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.

Cheers

5

Did you ever find a resolution?

6

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.

Cheers,

7

This still seems to be an issue on the recent versions of the API. While the documentation has been updated to indicate that a rate limit will result in a 429 response, in reality, it still seems to be returning a 303 response with no location header specified.