Update Core scenarios to support WA API item limit of 100

[thelontx]

In April 2024, WA updated their policy so that GET requests will return a max of 100 items. Existing customers were grandfathered, but new customers will have this limit.

Impacts/Considerations:
--Standard Make WA modules and the standard API calls will return a max of 100 results truncated, without notice of what was excluded.
--Newer API supports Contact Async calls where the request is submitted and then retrieved in a 2nd call. I assume that more than 100 records can be retrieved with the Async call, but it may not be true. QBWA does not typically have issues with retrieving multiple contacts.
--Newer API does not appear to support Async requests for invoices, payments, or events? (not in documentation - validate)
--Standard Make WA "get" invoice/payment modules only allow for Start Date as a parameter. Our existing scenarios use Start Date and then subsequently filter out any retrieved records that were greater than End Date. This could be improved by using the API module and specifying a Start and an End Date.
--QBWA customers running Daily will not be likely to hit the limit, but it is not a guarantee. Customers running weekly or monthly will more likely to be impacted.
--During initial QBWA install, historic transactions are often loaded. These will likely be impacted by the API limit.

Possible approaches/considerations:
--replace QBWA calls for invoices & payments with the equivalent API call using start date and end date

[asirota]

I have asked WildApricot to use the built-in Make.com supported pagination that is available when building apps. They can use the $top and $skip query params to retrieve the necessary data using pages of 100 results at a time to retrieve all necessary data without having to worry about the new limit. All the GET end points that return more than 1 row of data support this $top and $skip query params enabling paging to retrieve all the data returned by a call to these end point.