Kenshin

[onyx leaf]

Hi, you can check in this in the Dashboard but that information is not surfaced on the event payload.

[plucky vigil]

So there is no other way? I basically don't want to accept webhooks that are created by an API, so just to filter out those webhooks, if it makes sense

[onyx leaf]

Can yo clarify what this means 'I basically don't want to accept webhooks that are created by an API'?

[plucky vigil]

we have APIs that are calling stripe that update for example customer data, so it triggers the customer.updated webhook. And we do this based on certain logic that we have on our end, for example to update credit balance etc.. but then we also rely on the customer.updated webhook to update other fields, when finance make change on the billing portal for the customer. So it would be easy to check if the request is from the Dashboard or Automatic, to be accepted, and if is from API, to be ignored.

[onyx leaf]

Looking on my end

[simple salmon]

Hey. I faced some of these problems as well. My experience: The webhook events have a request property. This is null for events not triggered by a request (such as subscription renewals from Stripe). Events from the dashboard and from the API are indistinguishable in the event payload as they both have request IDs. What you can do is set your own idempotency key for a request and ignore that same ID in your webhook endpoints: https://stripe.com/docs/api/idempotent_requests - you could have it generate a random UUID and prefix it with something and then always check for that prefix.

Or maybe it's request->id that's null and not the request object itself. Edit: Yes:

"request": {
  "id": null,
  "idempotency_key": null
}

[onyx leaf]

I was able to test this and can confirm that you cannot get this level of information from the event payload. You'd need look at the Dashboard to identify if the event was fired from a request made via the Dashboard, or API.

I'll also share this feedback with the team for future product reiterations.