#nielsen_webhooks
tepid minnowBOT
👋 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/1433477641452916899
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
craggy badger
Hi 👋 I believe so, but am double checking that. While I don't think the minor versions will incorporate breaking changes from the API perspective, I do think you may run into troubles with minor versions having additive changes. I'll be back shortly.
Sorry, I'm getting ahead of myself. Did you pin your webhook endpoint to a specific API version, or is it using your Stripe account's default API version?
craggy badger
Gotcha, so if you change that version, then you will also need to change the SDK being used by the webhook endpoint to align with the version you're moving to. One sec, one of my teammates built a guide to help with this migration process.
random fulcrum
Ok cool. I did see that guide, the only thing I saw that was a bit confusing was "Starting with the 2024-09-30.acacia release, Stripe follows a new API release process where we release new API versions monthly with no breaking changes. " It implies that we can update our SDK, without needing to do anything with the webhook.
We have a renovate bot that updates patches and minor versions on dependencies. I'm worried that we won't be able to just update a minor version of the SDK without also using this guide to migrate the webhook
craggy badger
Yup, I was noticing that too and need to go chat with my teammates about that, as I'm not sure it's correct but I may be missing something. I'll get that guide revised if I'm not mistaken.
tepid minnowBOT
amber finch
👋 stepping in here as toby needs to step away.
Different minor versions do pin to different API versions, see: https://github.com/stripe/stripe-java/blob/master/CHANGELOG.md#3010---2025-10-29 for example which is the latest version and updated the API version while still on the same "major" versions (Clover).
So this means that you do need to stay aligned here to be able to properly deserialize new properties/objects.
So in sum you can't just update your API version without aligning the minor versions of the SDK as well.
random fulcrum
Add vice versa right? more than likely our SDK would update first via renovate bot.
amber finch
Not vice versa no.
Because minor versions won't add anything that would be a breaking change.
So everything should still deserialize as expected on a newer minor SDK version.
random fulcrum
Ah ok, that's what I'm missing then. So I can safely update SDKs so long as I don't go past the "name" of the API. So if my SDK goes from acacia to acacia, that won't require me to also update the webhook, but acaca to basil will?
amber finch
Sorry I'm actually incorrect here! These additive changes from minor versions will not break the deserialization process. We do call this out here: https://github.com/stripe/stripe-java/blob/master/CHANGELOG.md#2800---2024-10-29
Historically, when upgrading webhooks to a new API version, you also had to upgrade your SDK version. Your webhook's API version needed to match the API version pinned by the SDK you were using to ensure successful deserialization of events. With the 2024-09-30.acacia release, Stripe follows a new API release process. As a result, you can safely upgrade your webhook endpoints to any API version within a biannual release (like acacia) without upgrading the SDK.
So overall you can both update the API version within a major version or you can update the SDK to any version that still uses that major version of the SDK (as that will align with the major version of the API).
Basically we just ignore any additive properties upon deserialization.
That is how the SDK works.
So you are actually good both ways here
(As long as you stay within the same major version)
random fulcrum
Great, and I just lookout for the API version name change then (acacia -> basil)
amber finch
Yep