While testing our REST V2 conversion, we noticed that some of the long-form queries would fail. Specifically, they would hit a CURL timeout. (Which if removed would make the test queries last multiple minutes until manually cancelled. Working queries, like “List Contacts”, take a few seconds to grab similar numbers of items.)
We first noticed this with “List Orders”, which seems to trigger this issue on every call. We assumed it was this function in particular and noted it before moving on.
Then it appeared in “List of Payment Methods”. This one was both especially tricky to debug but also more helpful, since the first ~11000 records are successfully obtained, only to then fail on the 12th page. Using chunk sizes other than 1000, we were able to determine that the issue is quite consistently happening on the 11184th, 11185th, or 11186th payment method loaded. In addition, using the date filter, we could determine that this payment method was created on August 9th, 2024.
However, this is not the only payment method that causes the issue, this is just the first. Using date filters again, filtering through all of 2026 returns the same timeout failure. Filtering through September 2024 does too. Not every payment method triggers this, as at least October 31st, 2024 works just as intended.
We know based on the returned headers that this isn’t a throttling issue as described at API Token Quota and Usage Measurements - Keap Developer Portal . Each batch of calls is only 12 at most, and a 38 call “List Contacts” bulk query was successful (with appropriate wait times of course).
We’re assuming here there must be some data pertaining to us only that is breaking. (Although there is a similar forum post here where someone had certain pages breaking Endpoint for V2 / paymentMethods Fails after 2 page , we were not sure the resolution on that.)
If you need us to DM you our app id OR make a support ticket let us know, but we created this forum post since it does seem to be an issue that can happen to others. Presumably whatever bad data that can cause this problem needs to be identified and the endpoint needs to account for it.
As of now, this is a blocking issue for us and we cannot fully complete our migration to RESTv2 until it is fixed.
Thanks