#rob-quick_api
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/1447676009666187305
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Hello
It should still be working for the older API version. The fact that you're not getting the error mentioned means it's likely something else
Gotcha. I'm pretty sure we haven't changed anything about these api calls since this stopped working
Any idea about when it stopped working?
I don't unfortunately. We use it purely to show a pagination UI like "Viewing 1-20 out of 50" at the top of the table. User reported the bug around 12/5, but I feel something like this could have gone unnoticed for a while
Gotcha. I was just going to ask if there's any reason why you'd not switch to has_more which is the canonical way going forward
Can you share an example response you're getting from the API?
That's probably the solution we need to move toward regardless - I'm correct that there's no way to get a total count now as with my example, and if we want to show that on the UI we need to move toward storing these entities in our own db? Is there any reason to think it might start throwing a 400 level error before we make the next.
I don't think we're logging it, let me see if I can make one of these api calls directly real quick
The behavior you're seeing is likely a bug but a quick workaround here would be to switch to has_more
Trying to see if I can reproduce
hmm, yeah, when I make postman calls directly to the api using a test mode key - I do seem to see the total count. So either it's only affecting our prod account, or I jumped the gun about what the problem is. Let me see if I can make a prod key call
Sure, let us know..
Can you share the test mode request ID so that I can take a look?
req_r6fydQiplmJAAC
Thanks and have you double checked the live mode to make sure the parameter is definitely getting dropped?
Sorry for the delay, yep req_lpmdacp1gR1cvJ doesn't include total_count
(I believe those were otherwise made with the same parameters, but req_lpmdacp1gR1cvJ is against our real prod account)
the req_lpmdacp1gR1cvJ request is missing expand for total_count
Hmm, I was pretty sure I included in that one. Do you also not see it for req_Mzwbxc5CoOX5oS?
I see it on - req_Mzwbxc5CoOX5oS
ok - apologies, that one is also definitely missing total_count as well. Shape of that request response is:
{
"object": "list",
"data": [
{
<redacting prod client data>
},
{
<redacting prod client data>
}
],
"has_more": true,
"url": "/v1/balance_transactions"
}
got it.. I've reported to our Product team internally. I'll wait and see if they respond in a bit. If not, I'll probably have you write in and link it to the ask so that you can follow up
Hey we still haven't heard back from the teammate internally can you open a case with the link we're about to DM you? That way you can receive follow-up communications there.
Hello @orchid bear, we have sent you a direct message, please check it at https://discord.com/channels/@me/1447699033442488320
- 🔗The message has instructions on how to open a direct support case with our Developer Support team, in order to help you more effectively.
Done, opened as sco_TZKZU8sMk9ZgJO. Does it seem fair to say that we'll need to move off of this eventually. Having it removed on our current api version might be technically a bug. We can wait to see the response there, but ultimately we'd have to stop using it with the next upgrade?
Cool, thanks both of you for all your time today
Sure happy to help