#roshe10_webhooks

1 messages ¡ Page 1 of 1 (latest)

red domeBOT
#

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

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

versed willow
#

Hi there

#

I think the likely answer is that there may be some asynchronous processes involved with account updates that need to run before we send out account.updated and that you should wait for the webhook event, but let me look into it

burnt elm
#

thank you, so to repeat my main question is, will I have faster results calling the API couple of times after user is returned to "return url" or it will be the same as waiting for webhook in terms of waiting time for account updates (I need to know the state of onboarding as soon as user is in return url, to know whether they cancelled in the middle or actually completed it fully)

versed willow
#

So it sounds like you want to poll the API until you get the information you want

#

You can call the API as soon as the user returns to the return url but I don't know if we will always have finished updating the Account by the time that happens, and that's what I'm looking into now

#

Okay, I think we expect some delay between the user finishing onboarding and account.updated firing, so if you need to know as soon as they land at return_url then you should likely poll the API

burnt elm
#

so just to confirm, you saying if I poll the API on return url, it should give me updated account data before the event happens

versed willow
#

I'm saying it will give you the updated account as soon as the account is updated, which is why I say to poll the API. The timeline will be like this:

0: user submits onboarding form and is redirected to return url
1: you detect the user returning
2: GET /v1/accounts/:id #1
3: GET /v1/accounts/:id #1
4: GET /v1/accounts/:id #1
5: GET /v1/accounts/:id #1
6: GET /v1/accounts/:id #1

You may get the updated information anywhere from 2 - 6 or beyond. meanwhile, account.updated could land anywhere at 2 or after as well

burnt elm
#

so it's the same thing then ? I'm not getting anything by polling API, if API is not having newer info before account.updated

versed willow
#

It isn't because you don't know when account.updated is going to be delivered. It could be 4 seconds or 10 seconds or 60 seconds. Polling the API gets you the updated Account as soon as the update has happened in Stripe

burnt elm
#

okay, I think I get it, do you suggest any delay between these calls ?

#

also, how can I know for sure know whether user completed the flow and it's processing now on stripe side before charges and payouts are enables, versus client left the form in the middle. What are reliable field(s) to check, becuase in both cases payouts and charges could be disabled still

versed willow
#

I think probably you'll need to play around with the delay. Maybe something like calling on the quarter or half second would make sense.

#

we touch on this in our guide in the documentation

burnt elm
#

should details_submitted be enough to know whether they submited the form ?

versed willow
#

Yeah that should tell you if they actually hit the "submit" button

burnt elm
#

cool, that's what I need