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?