#nukesforbreakfast_docs
severe oakBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1252798672308015216
📝 Have more to share? Add details, code, screenshots, videos, etc. below.
north flint
hello! As mentioned in our docs : https://docs.stripe.com/api/idempotent_requests
All POST requests accept idempotency keys. Don’t send idempotency keys in GET and DELETE requests because it has no effect....
zenith hill
right, I don't
but the docs also say:
These requests are idempotent by definition.
so I found it odd the result is different between retries of the same request.
north flint
ah, sorry, I misunderstood the original question. I'm not sure I understand what you mean by 403 might actually be a 403 of this account was already deleted, do you have example requests ids which you can share? i.e. req_
zenith hill
I mean that if I run DELETE https://api.stripe.com/v1/accounts/acct_1234 twice in a row, simulating a retry due to a network error, the first request will return a success but the second request will return a 403 forbidden.
but, if DELETE is "idempotent by definition", shouldn't it return the same success code?
Here's a successful request: req_2I4I03Ywi8Jxtb
north flint
what it means by DELETE is "idempotent by definition" is that the state of the "system" will remain unchanged i.e. the object is already deleted and running that exact same request to delete isn't going to result in a different object state. It doesn't mean that the response for DELETE will always be the same
zenith hill
but when I run it a second time:
>>> client.accounts.delete("acct_1PSwIxBCTwlHegeo")
<Account account id=acct_1PSwIxBCTwlHegeo at 0x7fab889c0890> JSON: {
"deleted": true,
"id": "acct_1PSwIxBCTwlHegeo",
"object": "account"
}
>>> client.accounts.delete("acct_1PSwIxBCTwlHegeo")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/rccausey/.cache/pypoetry/virtualenvs/billing-api--M5yUIBR-py3.11/lib/python3.11/site-packages/stripe/_account_service.py", line 3334, in delete
self._request(
File "/home/rccausey/.cache/pypoetry/virtualenvs/billing-api--M5yUIBR-py3.11/lib/python3.11/site-packages/stripe/_stripe_service.py", line 32, in _request
return self._requestor.request(
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/rccausey/.cache/pypoetry/virtualenvs/billing-api--M5yUIBR-py3.11/lib/python3.11/site-packages/stripe/_api_requestor.py", line 196, in request
resp = requestor._interpret_response(rbody, rcode, rheaders)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/rccausey/.cache/pypoetry/virtualenvs/billing-api--M5yUIBR-py3.11/lib/python3.11/site-packages/stripe/_api_requestor.py", line 732, in _interpret_response
self.handle_error_response(rbody, rcode, resp.data, rheaders)
File "/home/rccausey/.cache/pypoetry/virtualenvs/billing-api--M5yUIBR-py3.11/lib/python3.11/site-packages/stripe/_api_requestor.py", line 321, in handle_error_response
raise err
stripe._error.PermissionError: The provided key 'sk_test_*********************************************************************************************1Iz7qc' does not have access to account 'acct_1PSwIxBCTwlHegeo' (or that account does not exist). Application access may have been revoked.
>>>
Oh, I thought idempotency meant the same result would be returned. This was based on: https://docs.stripe.com/api/idempotent_requests
Subsequent requests with the same key return the same result, including 500 errors.
north flint
it's not a Stripe specific behaviour, if you google for idempotency delete , you can find other explanations about this behaviour
zenith hill
ok, so it is only POST requests with idempotency keys where stripe guarantees the same result is returned?
north flint
we guarantee the same result is returned for POST requests for 24 hours when that idempotency key is first used to be specific
on a side note though, is there a reason why you don't want to rely on our SDK libraries in-built idempotency handling?
zenith hill
alright, well the issue still remains that the second DELETE results in a PermissionError or 403 status code instead of some other code, like a 404 NOT FOUND.
This means that I have to treat the 403 FORBIDDEN as a "we already deleted this account", when in reality it could be we accidentally rolled our API key and are using stale credentials. This leads to a case where the real error could be masked.
zenith hill
on a side note though, is there a reason why you don't want to rely on our SDK l...
Because in my use case I'm calling the Stripe APIs directly from an AWS Step Functions state machine. I can't use an SDK in that environment.
north flint
hrm, I agree that 404 would be clearer, I'll pass that feedback on to our team. However, logically, if your API key is stale, all of your requests would be failing and you would have an alert for that, not just that one specific request / endpoint