The documentation (https://help.shopify.com/en/api/guides/sell-through-the-checkout-api#polling) states that apps using the Checkout API should handle 202 and 303 messages properly.
How can app developers test their implementation of this polling mechanism?
We have tried to simulate this situation by creating multiple checkouts in parallel, but we were not successful in getting 202 or 303 messages, we received only 201 and 429 messages.
Can Shopify provide us with one or more of the following?:
- a procedure to reliably provoke the checkout api to respond with 202 / 303 messages
- a clear description of the exact header received in the case of 202 / 303 (the issue https://community.shopify.com/c/Shopify-APIs-SDKs/Polling-Queue-When-Creating-Checkout/m-p/523353#M3... seems to indicate that there is a discrepancy between what is documented and what is actually received in the header, at least in some cases)
- a test endpoint for 202 and a test endpoint for 303 that help to simulate this
As it stands we are unable to implement and test what we consider an absolutely critical aspect of the use of the Checkout API.
Looking forward to your assistance on this.
Let me expand a bit on when you'll see these statuses:
You should be able to test a 201/303 situation by surpassing 5 checkout creations in a minute from what I can tell, although you did mention that you were creating some simultaneously, so I wonder how many. A shop ID would give me more insight on that.
The 202 is going to be trickier and will likely require you to create a carrier service through which the rates will be requested on checkout creation.
I hope that helps a bit.
Thanks for the super clear answer. Very helpful indeed!
Regarding the 303s: we're not able to get the checkout service to send 303s.
Our test app (I can send it to you, you can run it easily on LinqPad) sends 36 requests to our test store (dev store with following domain: https://discount-ninja-dev-store-33.myshopify.com) creating a complex 15 line item checkout in parallel threads.
It receives a 201 response for all 36 requests within (milli)seconds.
This doesn't seem to be in line with the limitations you outlined in your answer.
Attached is a screenshot of the traffic recorded by Fiddler during the test.
Regarding the 202: any guidance on how to set up such a carrier service?
My assessment was definitely incorrect on the checkouts throttle (303s). So for platform protection reasons I actually can't go into specifics of how it works, but what I can say is that if you're using the checkouts API in a way that we would expect, like what we only ever really see, then you won't hit a 303 (we hardly ever see these as it would turn out). The best answer that I can really give in this case is to expect it and react accordingly, unfortunately I don't think we can provide a way for you to set it up in your testing.
For the carrier service:
You can create one with the carrier_service API - https://help.shopify.com/en/api/reference/shipping-and-fulfillment/carrierservice
If you've already understood that and have more specific questions though let me know. The best I can say without making any assumptions is that you'll probably want to be deliberately slow when returning rates to the checkout you're creating.
Thanks for your response. So, if I understand correctly, we shouldn't worry about 303s happening in real life too much, correct?
We also use the DraftOrder endpoint for our app, which can respond with "invoice is not ready" when using the returned invoice_url immediately. That behavior happens often in real life. I'll create a separate ticket related to that. I guess we expected the 303 result of the checkout api to be similar.
In conclusion: I guess we'll have to write our own test endpoint to mimic the 303 behavior.
Can Shopify provide an exact header that such a test endpoint should return?
Correct, it's unlikely that you'll be seeing 303s, so don't worry about it occurring often if at all.
I can't speak to which headers you'll receive as a response besides most typical ones in addition to the Location header, which which you can poll the checkout until it has been created.