#newtreyes-webhooks
devout raven
stripe should only turn off a webhook endpoint if the endpoint hasn't successfully processed a webhook (ie: responded with an http 2xx) in several days
if a webhook endpoint is only erroring sometimes, obviously that's not good, but stripe shouldn't shut off delivery
sick summit
That's weird
I saw a message telling that a specific webhook won't be delivered because it of the "webhook health"
but the rest of them were getting delivered.
It was a very specific type of event the one that was not being delivered
devout raven
what was the message?
sick summit
I wish I had taken a screenshot
but it mentioned webhook health
it said it was not sending it
but other events were getting delivered by Stripe and our endpoint was answering without a problem in the same webhook
when I resent those messages, the webhook was answering with a 200
so it was not as if it was failed, but that it was not sent
and the webhook was sending other events without a problem
devout raven
the only thing I can think of is if the way the webhook is set up in your dashboard is that there are multiple stripe webhook endpoints pointed at the same (or similar) endpoint on your side
for different event types or something
so that stripe thinks that the endpoint is completely down, but it's only a certain type of webhook that's affected
but it's hard to say without the IDs of the affected webhook endpoints, or some more details about the affected endpoint
sick summit
That's the thing
It was not fully down
Only a minority of them was not getting sent by Stripe
The rest were getting delivered
I was monitoring this as part of our smoke tests
devout raven
can you link the ID of the affected webhook endpoint?
sick summit
Yes
One sec
Here: we_1J2kD9LNS7fsUd0UDYraXUdv
This happened between 10 and 11PM Central Time yesterday
devout raven
I don't think that endpoint was ever disabled entirely
do you have a specific event that wasn't delivered to it?
it's possible that stripe backed off deliveries because the endpoint was struggling, and the event was just queued
sick summit
I think that was the case
But the strange thing was that other events in the same webhook endpoint were getting delivered
Let me give you some context about what I was testing
I was creating smoke tests for disputes
devout raven
I can see some event deliveries were skipped (but would have been retried later) because the webhook endpoint was returning a ton of failures
it's possible that's what you're seeing
sick summit
Yes
I think that was it
Let me give you some extra context
We are using Stripe connect
We have a single endpoint where we send all events for all clients
from there, we find the specific client the event is related to and we route it to their endpoint
Now, this is a thin redirection layer
if the client throws back an error, we send it back to Stripe
so one big enough client could get us into hot water
and get us to the point where stripe starts skipping some events for all our clients
So, I am considering always answering with a 200 to stripe but handling issues internally
Does that sound like a reasonable plan?
devout raven
yeah, that sounds like what you want
one way of doing this is to have your webhook endpoint push the event data into a queue, and then you internally deliver the webhook to the client
sick summit
Yeap
devout raven
another thing you could do would be to use connect to create a webhook endpoint specifically for that client, and let stripe do the webhook delivery
depending on how thin exactly that redirect layer is
sick summit
Well, correct me if wrong but endpoints cannot be client specific
can they?
We are using Custom Accounts