#scif_unexpected
1 messages ยท Page 1 of 1 (latest)
๐ 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/1376713408002654333
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- scif_unexpected, 3 days ago, 35 messages
Hello, we don't save successful GET responses so can you share the full response for what you received in the request?
hi @bright leaf , its due to the same issue. You're making the request too fast. The GET call was made at
2025-05-26 05:50:26 UTC, which is the same time the invoice object is created.
Sorry but this is outrageous behavior
If your backend doesn't have data โ please let us know about it
As recommended by alex on the previous thread, please wait for the checkout.session.completed event, which was emitted at 2025-05-26 05:50:27
FAil the request, mark it with a proper status
Or whatever else, but not serve data which is marked as full/competed/valid in the shape of inconsistent objects
I admit your point, it could be the case that data is not available but in this case the status of an object (checkout session) must be appropriate
Otherwise you are producing invalid and inconsistent code claiming it's as complete
I understand your frustration with this limitation, but as Alex mentioned earlier, the best workaround now in this case for the current API behavior requires waiting for the checkout.session.completed event to retrieve the Invoice ID. Unfortunately, there isn't a more efficient workaround available in the current implementation.
Yep, I'm reworking my code now but I'd appreciate if you would lodge this as a bug report. Serving of inconsistent data and moreover wrong types is actually a bug.
It'll be better if you write in yourself. It means little if I raise the feedback since I don't know who you are, if you write in to support then you're authenticated and the feedback is raised on your behalf so we can get a better sense of impact, we can track it and let you know directly if something changes or if we need more input and so on.