#mursk_api-upgrades-webhookevents

1 messages ยท Page 1 of 1 (latest)

nova sinewBOT
#

๐Ÿ‘‹ Welcome to your new thread!

โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always 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/1281290218355298398

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

abstract stag
#

Context screenshot of what I'm referring to:

worldly axle
#

This will update the default API version for your account and it will apply to both Test and Live mode.

To test out this API upgrade, we recommend specifying the new API version in a dev environment using your Test mode API keys. SInce you are using an SDK that pins the API version, that would mean upgrading the SDK version in your dev environment only since that will automatically add the Stripe Version header to your API requests.

abstract stag
#

@worldly axle Got it, so I actually have a branch with the Stripe.net package v45.7.0 deployed to a QA environment. While the requests are now coming through with the API Version 2024-06-20, the webhooks I need to test are coming through with the previous Default version. Is the only way to have webhooks sent with an updated version to actually do the full upgrade?

worldly axle
#

In that case, it's recommended you create a new webhook endpoint for your Stripe account that uses the latest API version and point it to your dev integration.

abstract stag
#

I have that set up as well, but even though my Webhook is set to 2024-06-20, it's Event deliveries are all 2023-10-16, which seems incorrect.

#

Even though the API invocation that generated the event is also 2024-06-20.

#

Here's some IDs if they're helpful.

POST /v1/subscriptions: req_QDhTQCM7Ozpl24

customer.subscription.created: evt_1PviUaIGBnsLynRrxtR4TQCX

worldly axle
#

Looking at this event, it looks like we did deliver an event using 2024-06-20 and 2023-10-16 to the CLI. But other endpoints received much earlier API versions.

abstract stag
#

Is there a way to see the record of the 2024-06-20 one being delivered? I can't find any indication of it in workbench.

worldly axle
#

It was sent to the CLI placeholder but it looks like your CLI wasn't running at the time. The response body has {"type":"no_active_websockets"}

abstract stag
#

Sorry, bit confused on that, but if you don't mind, here's just one more example:

invoice.payment_succeeded: evt_1PviUcIGBnsLynRrL7LhMBZd

The request to create a subscription that generated that event was sent with the 2024 version. So why would that specific event have the 2023 version? Is the event version completely dependent on your account's default version and not the API invocation that generated it?

worldly axle
#

What registered webhook endpoint are you listening to?

#

The first delivery attempt (to the CLI) that I look at has the following

  "id": "evt_1PviUcIGBnsLynRrL7LhMBZd",
  "object": "event",
  "api_version": "2024-06-20",
  "created": 1725553507,
abstract stag
#

Weird, okay I found the request body for the delivery and you're right it has the correct version. Alright there must be something else going on that I'm not seeing. Apologies for the run around there. Appreciate your help though.

worldly axle
#

No worries! It's why we're here ๐Ÿ™‚