nicolas_dotnet-webhook | Stripe Developers | Page 1

distant vineBOT Jun 4, 2024, 1:14 PM

#

👋 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/1247538887052759090

📝 Have more to share? Add details, code, screenshots, videos, etc. below.

elder tinsel Jun 4, 2024, 1:16 PM

#

Hi there 👋 you should be able to upgrade to whatever version you prefer which works well in your testing.

If you create your Webhook Endpoint through the API, then you can specify a particular API version that the endpoint should use via the api_version parameter:
https://docs.stripe.com/api/webhook_endpoints/create#create_webhook_endpoint-api_version
That parameter will accept any valid API version, not just your current default or the latest. There are limits around the number of different API versions you can have endpoints set up for though.

Create a webhook endpoint | Stripe API Reference

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

hidden pelican Jun 4, 2024, 1:17 PM

#

oh meaning that I could update just to 41.27 - 2023-08-03 API version and not having to update to the latest version? Which are those limits that you mentioned?

elder tinsel Jun 4, 2024, 1:19 PM

#

Yup, that should work. I don't recall the exact limit offhand. I think it's around 3-5 different API versions, but I'll try to test that to confirm when I get a second.

hidden pelican Jun 4, 2024, 1:19 PM

#

Awesome!

#

Another question...

#

Which would be the proper way to release an upgrade? Specifically talking about that I will perform the upgrade on the SDK of my API having to apply code changes due to new structures/types based on the new SDK version. How should I handle the release of these changes and taking into account that it might be possible that I deploy my changes and existing events might occured and not been proccesed

#

Having the possibility of old events with the old API version not processed and my API code it's already in the latest version

#

latest or newer one, doesnt matter

#

Let me know if I explain my self correct

elder tinsel Jun 4, 2024, 1:24 PM

#

You should prepare your webhook endpoint for the change first, by standing up a new one to use. Then you'll likely want to put filtering in your Event handling code that runs on your endpoints, checking for the API version of the Evnt being received and ignoring ones that don't match the version of the endpoint. That way you have two endpoints running during the cutover and won't miss Events.

hidden pelican Jun 4, 2024, 1:27 PM

#

okay, you mean that when I upgrade the SDK, in the webhooks handling I should check the API version of the event. If it's lower than the one that I update I shouldn't process that event.

#

Correct?

elder tinsel Jun 4, 2024, 1:28 PM

#

Yup, but give me a second to think through that again, I'm thinking I misremembered this.

hidden pelican Jun 4, 2024, 1:28 PM

#

Or you mean that before performing the upgrade of the SDK I should add that check?

#

sure!

#

I think it makes sense what you described but I imagine that I would have to create the new webook (with the new API version) before I deploy my code changes

#

meaning that until my code it's deplyed if I don't add that check of the API version before I deploy the SDK upgrade, it might be possible that the API process the same event multiple times

#

Because the old and new webhooks are gonna be triggered I guess

elder tinsel Jun 4, 2024, 1:30 PM

#

The problem with the approach, that I forgot about, is that the api_version in the Event should always match the version of the endpoint receiving it.
https://docs.stripe.com/api/events/object#event_object-api_version

The Event object | Stripe API Reference

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

hidden pelican Jun 4, 2024, 1:32 PM

#

Okay, so based on what you are describing in the case I explained above, if I have two webhooks listening to the same event one with old API and the other one with the new API

elder tinsel Jun 4, 2024, 1:32 PM

#

But since you're working with our dotnet SDK, which is a strongly typed language so we have to pin SDK versions to API versions, the version on the Event also needs to match the version of the SDK being used.

hidden pelican Jun 4, 2024, 1:32 PM

#

Both will triggered an event to my API but only one will be proccesed since the API version will match with only one?

#

If the SDK upgrade was not deployed yet it will be the old webhook the one successfully processed and ones the changes are deplyed the new one

#

?

elder tinsel Jun 4, 2024, 1:36 PM

#

Not necessarily. When an Event is sent to an endpoint, we render it based on the API version of the endpoint receiving it.

So if an Event is triggered by one API version, but then sent to an endpoint using a different API version, we adjust the Event so it matches the API version of the endpoint.

hidden pelican Jun 4, 2024, 1:36 PM

#

oh intresting

#

So if that's the case, I'm not really understanding which should the proper way to perform the upgrade deploy haha sorry

elder tinsel Jun 4, 2024, 1:38 PM

#

Haha, totally understand, I haven't made it clear. I'm not sure if I'm just running low on coffee which is why I'm blanking on this, but am checking with my teammates.

hidden pelican Jun 4, 2024, 1:39 PM

#

haha no worries! Sure, check with them and let's have another opinion

elder tinsel Jun 4, 2024, 1:46 PM

#

Alright, I've got it now, sorry about that 😅

hidden pelican Jun 4, 2024, 1:48 PM

#

No worries

elder tinsel Jun 4, 2024, 1:54 PM

#

So stepping through that:

First, make sure you test new Event handling code that can work on the new version. We can talk through this in more detail if need be, but it's less about the cutover process so I'll leave it high-level for now.

for the cutover:

Create a new disabled Webhook Endpoint, using the API version that matches the version of the SDK you plan to upgrade to. We suggest pointing this to the same URL where you're currently receiving Events, but including a query param in that URL so you can easily filter Events based on what endpoint received them in your code.
In your Event handling code on your endpoint add your new code for handling the new API version, but only have this be called if the API version in the query param matches the API version the SDK is pinned to. You should also add similar filtering the Event handling code that was already running, so it will stop being used when you switch SDK/API versions.
If an Event is received in a version that doesn't match the library's pinned API version, the library won't be able to deserialize the Event and will throw an error. You should add error handling to catch those so your code doesn't break.
At this point you should be able to enable the new Webhook Endpoint. You can leave the old endpoint running, as it should stop processing Events once you update the SDK version and it stops being able to deserialize the Events.
Upgrade the SDK version

As always, I'd strongly recommend stepping through this process in a test/qa environemnt before doing the same in production to triple check everything will go smoothly.

hidden pelican Jun 4, 2024, 1:59 PM

#

Cool. I think it makes sense what you describe. What happend with what you've mentioned that the Stirpe will try to parse the event to the proper API version that the SDK uses?

elder tinsel Jun 4, 2024, 2:00 PM

#

We'll still do that

#

What happens is you have two endpoints sending Events to the same code, but that code is only running one version of our SDK at a time which is pinned to a particular API version. So only the Events from one endpoint will have a rendered API version that matches the API version the SDK is pinned to.

#

Therefore the SDK will only be able to deserialize one set of Events at a time, when you update the SDK version, it should switch which endpoint can do the deserializing. (a little confusing since both endpoints point to the same code)

hidden pelican Jun 4, 2024, 2:02 PM

#

Agree, and I add the API version filter it will never be proccesed if the version doesnt match

#

Now, which would be the proper time to enable the new webhook? Once the code changes are deployed and stable right?

elder tinsel Jun 4, 2024, 2:08 PM

#

Yup, once you've tested and confirmed the new Event handling code works for the new API version, you can deploy that code to be used by the endpoint running on the newer version. After the new endpoint is enabled, you can upgrade the SDK version being used in the endpoints.

hidden pelican Jun 4, 2024, 2:11 PM

#

That last part is confusing me. How could be that the SDK upgrade is the last step? The new event handling should have already the SDK upgrade since probably the types and new things appear

#

It's impossible to create the new handling compiling without performing the upgrade of the SDK version

elder tinsel Jun 4, 2024, 2:15 PM

#

Hm, do you have an example of the compilation error you're encountering? The two sets of Event handling code are all running in the same place, so they'll be using the same SDK version. The new code won't be used until the SDK upgrade, at which point the logic you added to match the API version in the endpoint's query param to the API version the SDK is pinned to will begin using the new event hanlding code instead of the old code.

hidden pelican Jun 4, 2024, 2:17 PM

#

Let me put a clear example. Im not sure in which verdion but payment intents doesnt have charge property. Now are called latestCharge

#

If I'm creating the new handling event if I don't update the sdk my payment intent object won't have the latestCharge property until I update the sdk. Make sense?

hidden pelican Jun 4, 2024, 2:41 PM

#

are u there?

elder tinsel Jun 4, 2024, 2:42 PM

#

Yup, makes sense! Sorry for the delay, was checking more with my teammates.

hidden pelican Jun 4, 2024, 2:46 PM

#

Then you agree with me that the update of the SDK have to be made at the same time I;m adding the changes for the new event handling

elder tinsel Jun 4, 2024, 2:46 PM

#

Yup, which is exactly what my teammate is saying too.

hidden pelican Jun 4, 2024, 2:49 PM

#

Cool, now the question that I have is:

If I didn't understand incorrect in your step-by-step you refered to have in the code the two implementations of the event handling depending on the API version and using the parameter API version filter. I think that's not possible based on what I explained earlier. If update the SDK only one of those approaches will be valid. Meaning that only one version could live in the code

elder tinsel Jun 4, 2024, 2:49 PM

#

Yup

hidden pelican Jun 4, 2024, 2:57 PM

#

Based on everything we had talked, can we refresh the proper step by step

#

?

#

To achieve the proper upgrade?

#

Because again, some of the points you mentioned and with what we have discussed are contradictory

elder tinsel Jun 4, 2024, 3:01 PM

#

Ha, you seem to understand this better than I do, what part are you unsure about?

hidden pelican Jun 4, 2024, 3:05 PM

#

haha. I'm unsure on how to properly make sure that events not proccesed triggered with the old API version get never proceesed

#

That;s my concern

#

And also, how to properly handle a rollback in case it's neccesary. Of course I'll have to do the rollback of the code and disable the new webhook but to understand if there's a way to trigger the events that were triggered with the new version to re-trigger them with the old version since we had to perform the rollback

elder tinsel Jun 4, 2024, 3:13 PM

#

I think here it depends on how exactly you structure your Event handling code for your endpoints. Would you be able to structure your code so that each webhook endpoint can use a different version of our SDK?

hidden pelican Jun 4, 2024, 3:18 PM

#

Unfortunately, as I mentioned no. Once I update the SDK the old API version handling will stop compiling becasue the structure of the object will change. It's not possible to have multiple SDK versions

elder tinsel Jun 4, 2024, 3:22 PM

#

Gotcha, if your code is structured in such a way that each endpoint has to use the same SDK version, then I think you need a slightly different approach from what I've been describing. I was going to suggest having the old endpoint continue capturing Events, but not processing them on your end, so that way in case a rollback is needed you have those Events that you can process with your old code.

#

As always, I'm open to your input here, but what if you did this?

Create a new disabled webhook endpoint, using the new API version.
Add code on your side for that new endpoint, that only responds to us with a 200 indicating it received the Event successfully. That shoudn't be API-version specific, so I think you'd avoid build errors there.
Enable the new endpoint, which shouldn't be doing much at this point.
Deploy your larger code change, which would push the new, tested Event handling code to the new endpoint, pulls in the new version of our SDK, and also adjusts the behavior of the old endpoint to just respond with a 200 (and possibly log the request contents in case you need to process those later)
Disable the old endpoint after confirming the new endpoint continues to successfully handle Events as expected.

distant vineBOT Jun 4, 2024, 3:46 PM

#

hallow stirrup Jun 4, 2024, 3:46 PM

#

nicolas_dotnet-webhook

hidden pelican Jun 4, 2024, 3:47 PM

#

That makes more sense. Quick question, Once I've added the new Webhook in Stripe, the events will be triggered in both webhooks right? The new and the old one

#

Hi @hallow stirrup !

hallow stirrup Jun 4, 2024, 3:47 PM

#

Hello! And yes to your last question

hidden pelican Jun 4, 2024, 3:48 PM

#

Cool. So then let me see if what I have in mind will work

#

1 - Create the new webhook with the new API version in Stripe (Disabled)
2 - Update Stripe SDK and the logic for processing those events in the code with the new webhook. (Add a check that if the event has the old API version do not process it, only new ones).
3 - Deploy code changes.
4 - Enable new webhook.

Now my question is, how should I properly handle the timing on Steps 3 and 4? Because it might be possible that events occurred during those two steps.

#

And If I enable the new webhook before deploying the code changes it might be possible that the same event gets processed two times since the old code will not have the API version check unless Stripe it self throws an error since the API version doesn't match.

hallow stirrup Jun 4, 2024, 3:55 PM

#

you didn't really number steps so it's not easy

#

But I would enable the new endpoint before deploying the new code

hidden pelican Jun 4, 2024, 3:57 PM

#

Makes sense and how would you handle what I described?

#

The fact that it might be possible to have the same event triggered by the two webhooks, the code will be prepared only for the old webhook

#

It will throw an error and those events are not going to be processed until the new code it's deployed?

hallow stirrup Jun 4, 2024, 4:05 PM

#

You have 2 separate WebhookEndpoints. A is on version X and B is on version Y. Right now you code is live with version X so it processes those and ignores the ones with version Y (return a 400 for example)
You deploy your new code with version Y, you now ignore all Events with version X and process the one(s) with Y instead.

Once you're ready you can delete the old WebhookEndpoint with version X to stop all those deliveries/retries since your code now expects Y

hidden pelican Jun 4, 2024, 4:09 PM

#

Awesome! Anyway I will test these in lower environments to make sure that If an event with version X is triggered and the code is prepared for version Y it's throwing an error or something and not processed.

#

Last question I'll promise :). What do you suggest in terms of the new webhook URL? Let's put the following example, today I have https://something.com/api/webhooks/paymentintents that listen to multiple payment intents events. The new webhook should have the same URL?

#

I think that in the payload of the event a property api_version it's send so I don't need to add any additional parameter to the webhook URL

hallow stirrup Jun 4, 2024, 4:12 PM

#

I would add a clear query parameter to the URL so that you can easily distinguish which is which

#

so https://something.com/api/webhooks/paymentintents?apiVersion=X and https://something.com/api/webhooks/paymentintents?apiVersion=Y

#nicolas_dotnet-webhook