#mikebm-webhook-error
errant totem
unreal herald
Our response header for Content-Type
text/plain;charset=ISO-8859-1
errant totem
Hey there 👋 do you have any insight into the cause of the error being thrown by your server?
I'm asking because the response you send to us should simply be to indicate whether or not the request was received. The response should not be used to surface errors encountered by your processing logic.
unreal herald
We do, in today's case it was a communication error with AWS, in other cases it's because customer service issued refunds through the Stripe UI which we throw an error for because we cannot do tax audits for these since we have no idea what is being refunded on the invoice.
In these cases, we return some text in the response where we hoped we could view said text in the webhook failures, but if that's not supported then we will have to jump through a few hoops to look in datadog
errant totem
I'd need to double check whether it's actually possible. The concern with this though, is that when we receive an error we believe you couldn't receive the event and will continue trying to resend it.
unreal herald
yeah, that's expected. In certain cases, it would be nice if we could return a status code that is an expected error and stripe will stop retrying.
We don't return 200 for these because it helps us identify a misuse of our system.
errant totem
Completely understand the desire here, but we will retry for any none 2XX status code. You could ty returning a 2XX status code other than 200 to serve as a differentiator (though I'm not certain which one would be a good fit off the top of my head).
https://stripe.com/docs/webhooks#built-in-retries
The other thing to be cautious of, is that our webhooks have a 20 second timeout so you'll want to avoid any processing logic before you send us a response to avoid exceeding the timeout limit.
unreal herald
Good to know. Thanks.
errant totem
Any time!