idempotency key with webhooks

[Robin Williams]

Hi

If an API call is successful, but the response is lost, the requestId is unknown.

If one or more webhooks is subsequently generated, it is therefore not be possible to identify them as having been generated from the API call.

If the idempotency_key is also included in the webhook (header or body), then it will be possible to identify it came from the API.

How easy would it be for you to include idempotency_key with webhooks?

Thanks very much

Robin

[Remi J.]

Hey Robin,

Usually, if you don't get the response to your request you should run it again with the same idempotency key. This way, you get the response to the original request back. At that point, you know which object was created, with its id, and you could react to the corresponding event accordingly even without knowing the exact request id (req_XXXX) that created the object in the first place.

I do see how having the idempotency key in the event could help make the reconciliation easier though. I'm not sure if this is something we could support in the future but I'll raise this to the team in charge of webhooks/events to see if we could consider this!

Have a great week!

Remi

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss+unsubscribe@lists.stripe.com.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at https://groups.google.com/a/lists.stripe.com/group/api-discuss/.

[beni...@gmail.com]

Include your key in your metadata and it will be present in the webhook posts. 

Sent from my iPhone

--

You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.

[Robin Williams]

Hi Remi

Thanks for your response.

But what happens if a webhook is generated before the call has been retried?  At that stage, we do not have a requestId on our server and therefore have no way of knowing the webhook comes from the API and would therefore treat it as though it has come from the dashboard.

It would of course be ideal if webhooks included an attrribute of where they were generated - API, dashboard or automatic, then we would not need to do all this complicated stuff.  Would it not be possible for the stripe code to use the IP of API requests to determine if it is from a dashboard server?

Thanks

Robin

On Monday, May 8, 2017 at 2:20:58 PM UTC+1, Remi J. wrote:

Hey Robin,

Usually, if you don't get the response to your request you should run it again with the same idempotency key. This way, you get the response to the original request back. At that point, you know which object was created, with its id, and you could react to the corresponding event accordingly even without knowing the exact request id (req_XXXX) that created the object in the first place.

I do see how having the idempotency key in the event could help make the reconciliation easier though. I'm not sure if this is something we could support in the future but I'll raise this to the team in charge of webhooks/events to see if we could consider this!

Have a great week!

Remi

On Mon, May 8, 2017 at 3:52 AM, Robin Williams <ro...@soulcontractconnect.org> wrote:

Hi

If an API call is successful, but the response is lost, the requestId is unknown.

If one or more webhooks is subsequently generated, it is therefore not be possible to identify them as having been generated from the API call.

If the idempotency_key is also included in the webhook (header or body), then it will be possible to identify it came from the API.

How easy would it be for you to include idempotency_key with webhooks?

Thanks very much

Robin

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.

[Robin Williams]

Hi Ben

Might work for some calls, but not all API calls allow for metadata to be added.

Robin

[Remi J.]

Hey Robin,

You could technically store the event in a queue if it's about a resource you don't know about and you'd flag the event to be checked. Once you retry the request with the same key and get the resource details you can check if you have a pending event waiting to be matched to an API request. You'd then timeout after X minutes if the event hasn't been matched and assume it was made in the dashboard.

This definitely feels hacky though and I definitely hear that a flag on the event if the resource was updated in the dashboard could help solve this. It's something we've thought about in the past and I'll start the discussion again.

All the best,

Remi

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss+unsubscribe@lists.stripe.com.

[Brandur Leach]

Just to close the loop on this one, we've expanded the

`request` field under events to be a full object [1] in API

version 2017-05-25. It now contains an idempotency key

along with a request ID.

Brandur

[1] https://stripe.com/docs/api/python#event_object-request

[2] https://stripe.com/docs/upgrades#2017-05-25