I use this scenario to pull archived orders from our booking platform (Booqable) and update them in Airtable. The limit for the number of orders that can be pulled is 1,000. I never thought we would reach that but here we are!
Currently, I pull all archived orders and then filter after the Iterator module based on when they were updated. As I only need to update orders that have been updated or created in the last 48 hours.
I see two possible solutions but I’m not sure how to execute on either of them.
Add additional filter to API Call so only those orders updated in last 24 hours are retrieved.
Complete API Call, store data from 1st Call, repeat Call (retrieve different data), process all data together.
Are either of these options possible? Or is their a third option I’m unaware of?
Seems the simplest method, however, I can’t figure out the additional filter. Would it be an additional query string?
API calls in this form are right at the extent of my knowledge so feeling a little lost. Any help is welcome!
The way we’ve implemented paging previously is to use webhooks and use multiple scenarios.
So you have a starting scenario which sets up any config required to run the web calls like url, page no, no of items per page and so on, and this passes those config options to another scenario via an http call to the scnerio’s webhook address.
The second scenario then makes the api calls to Booqable specifying the page number each time and updating it by 1 before then calling itself at the end of the scenario with the updated config options if you haven’t processed all pages/data yet.
In your scenario as you cannot limit the returned data by date (lame Booqable, very lame!) then you could make an initial call to the api to find out the total orders, do some maths to work out the pages required (based on how many you want each time) and then do the calls in reverse. I would do this in scenario 1 to get your starting page number before hitting the webhook scenario.
This way you will get the last page, then the next to last and so on. As soon as you hit an order which is below your 48 hour threshold you can then force an error to stop execution and prevent the webhook being called again and using pointless operations processing data you just don’t need.
