#elliott
fossil tusk
Hello 👋
Can you share the event ID you're looking at?
shut fern
evt_1N3ft2D11gJy8IX8Ej7wMHDS
all events for the webhook have the issue, we_1N3fN0J1qHYDbkNrc7Ca5lqj
shut fern
another data point, i have an existing webhook which is set to the older version (the account's version). i tested upgrading the account, it changed the version of the existing webhook. my understanding is that is not suppose to happen.
i rolled back the version after seeing it changed the existing webhook.
fossil tusk
huh I can't seem to reproduce this on my end. I wonder if the existing webhook on the older version doesn't really have a version attached to it.
It almost feels like its linked to the Account API version.
Can you try re-creating the endpoint with the old API version but the same URL?
jaunty slate
Hey, another team member here.
We have version 2020-08-27 and version 2022-11-15.
The account is set to 2020-08-27.
Which version should we put in the re-created endpoint? We didn't fully understand the ask.
fossil tusk
2020-08-27
jaunty slate
The backend won't accept anything other than 2022-11-15, so our goal is to get the webhook to be sent that version.
What will we hope to see in this test?
fossil tusk
I am hoping that it would tell Stripe to generate events for both API versions, 2020-08-27 and 2022-11-15
jaunty slate
Oh, so at the end of doing this, we'd have two webhooks pointing to the same endpoint, one at each version?
worthy otterBOT
fossil tusk
Ah let me clarify
You currently have two webhook endpoints
Webhook A -> on version 2020-08-27
Webhook B -> on version 2022-11-15
Account API version is 2020-08-27
Now, ideally we should generate events for both API versions above but it seems like we're only generating events for 2020-08-27 API version
Also webhook A's API version changes when you update the account API version, which shouldn't be happening if the endpoint has an API version that's set.
So I am thinking that webhook A's API version is linked to the Account API version (not static, changes dynamically)
My hope is that re-creating Webhook A with the same info would likely set the API version statically
jaunty slate
So we added the 2nd webhook. So we have two webhooks, each pointing to the same URL, one at each API version.
The 2022 one is now receiving at least some events in 2022 API version.
The 2020 one is seeing 2020 events.
But Webhook A isn't the problem. It's pointing to a different backend.
fossil tusk
The 2022 one is now receiving at least some events in 2022 API version.
The 2020 one is seeing 2020 events.
I believe that's the expected beahvior
But Webhook A isn't the problem. It's pointing to a different backend.
Right, what I meant was use the same URL that was there on webhook A
jaunty slate
Sorry, I'm worried we may be talking past each other and have muddled the situation. 😦
fossil tusk
I think the "use the same URL" was the confusing bit here, my bad
jaunty slate
This account had:
Webhook A (version 2020 of the API) - points to backend 1. Has always worked fine.
Webhook B (version 2022 of the API) - points to backend 2. It's receiving 2020 events, despite us explicitly setting the webhook version (you can see that in the screenshot).
We've now created Webhook C (version 2020 of the API) - points to backend 2. It's receiving 2020 events (as we'd expect).
fossil tusk
Gotcha. What I meant to say was,
1/ Disable webhook A temporarily
2/ Create webhook C - on older API version - pointing to backend 1
My expectation is that creating webhook C with the same URL (to backend 1) and old API version would set the version statically.
So webhook C's API version shouldn't change when you upgrade the account API version
does that make sense so far?
jaunty slate
It could make sense, but is it clear that we don't need to make any changes to Webhook A (our production one), but we want to get Webhook B working (our new development version), so we can test before launching it and replacing Webhook A?
fossil tusk
Yup totally get that, that's why I recommended using backend 1 URL on Webhook C.
jaunty slate
Webhook C at that point would be a duplicate of Webhook A. They both would point to the same URL and the same API version.
fossil tusk
Yes, but my understanding is that Webhook C would not be upgraded to latest API version automatically when you upgrade the account API version
which is what's happening with webhook A
jaunty slate
Oh, OK. That's a side observation. We're not too worried about that, to be honest. We just didn't know if that was expected or not.
Since Webhook A was created with a "null" API version, we're assuming that just lets it stay with whatever the account is set to.
Honestly, we shouldn't have brought it up. We're just focused on getting Webhook B to get 2022 events.
fossil tusk
If you change Webhook C to point to backend 1, does that affect the API version of the events you're receiving on Webhook B?
jaunty slate
No it didn't, sadly 😦
The only thing that has affected the version of events sent to Webhook B has been changing the account API version.
(We tried upgrading the account version to 2022 temporarily, and then reverted it after we discovered it did in fact upgrade the events we got on Webhook B)
fossil tusk
ugh so weird, my test account has the same API version 2020-08-27
I can't seem to reproduce this on my end. I receive different events based on the webhook endpoint API version
jaunty slate
(That's where the side observation came from that it also changed the displayed API version of Webhook A. When we changed the account API version back to 2020, Webhook A reverted to display an aPI version of 2020, but Webhook B continued to show an API version of 2022, even though the events it receive are 2020).
Is your test webhook a Connect webhook? Ours are.
We tried another test just now:
We created a new webhook (Webhook D). This is an ACCOUNT webhook. It's set to version 2022 of the API and points to backend 2.
It is receiving 2022 events. However, even if we remake our CONNECT webhook (Webhook B), it still gets 2020 events.
fossil tusk
Interesting.. So only connect events are ignoring the API version on the endpoint.
jaunty slate
Potentially. Or, we're not fully understanding what controls the version of Connect webhooks 😦
fossil tusk
Asking a colleague to take a look here too, I must be missing something
jaunty slate
Sure thing. We appreciate the help. 🙂 We know it's a crazy day for people at Stripe! Happy Sessions Day!
fossil tusk
You mentioned you're only seeing this behavior with some type of events
What types are these?
jaunty slate
One second, that's a good question. We're testing and then we'll fill you in.
fossil tusk
👍
jaunty slate
Interestingly, on our Connect Webhook:
customer.created -> sends in 2022
account.application.authorized -> send in 2020
account.application.deauthorized -> send in 2020
But if we have all three enabled on the same webhook, set to 2022 API version, then, when we trigger a customer created event, the webhook page won't even load. It says "Error" and there's a 500 response in the network tab and developer console.
If we create a Connect Webhook with only customer.created, then it works
We're not sure how we did it, but after a couple tries, we did get a Connect Webhook with all three events enabled. And we've confirmed that the customer.created events are coming in with API version 2022, but the account.application.* ones are coming in with API version 2020, despite the Webhook being set to 2022.
ashen nexus
Hi yeah I chatted with hanzo right before on this issue and checked with the owning team. This issue is actually a known one specifically with account.application.authorized and account.application.deauthorized events on Connect accounts. The issue shouldn't effect any other event types.
I will raise a ticket internally about this with the team
jaunty slate
OK, great to know, thanks!
ashen nexus
But no guarantees on when they'll fix it by
jaunty slate
Sure, we understand