For this API, it looks like the HistoricalAdherenceActuals array is not included. Is this going to be added any time soon or is there another bulk API I can use to get the HistoricalAdherenceActuals?
Thanks,
Trey
For this API, it looks like the HistoricalAdherenceActuals array is not included. Is this going to be added any time soon or is there another bulk API I can use to get the HistoricalAdherenceActuals?
Thanks,
Trey
Hi Trey,
You are correct that the actuals are not included in the Historical Adherence bulk API results. If you want to query actuals to go along with the results from the Historical Adherence bulk API, you can make use of Analytics APIs to get the actual values directly. APIs that can provide these are:
/api/v2/analytics/users/details/query
/api/v2/analytics/users/details/jobs
The query route returns synchronously with pagination, but is limited to 558 days in the past. If you need actuals earlier than that, then you would have to use the jobs route which has no limits but is asynchronous.
If you require the actuals to come back with the historical adherence data, then I would instead recommend using our management unit based route, listed below, to request for each management unit individually instead of in bulk.
/api/v2/workforcemanagement/managementunits/{managementUnitId}/historicaladherencequery
Thanks Dan!
I am currently using the historicaladherencequery route you mentioned but I'm getting rate limited like crazy, so unfortunately the bulk api doesn't help me much in my situation. This is what I needed to hear. I appreciate the response!
I know the bulk api does have some extreme rate limiting. But in case you do want to give it a shot again in the future, I wanted to give you a little more info on it. It actually limits in two different ways, there is a normal rate limit that currently limits you to only 5 requests per minute, but there is also a concurrent limit that limits you to only 2 requests processing at a time. So for example if you send in 2 requests and then try to send in a 3rd before either previous request has finished, it will give you back a 429. The normal rate limit response also includes a Retry-After header that tells how many seconds until the rate limiting is gone and you can request again. The Retry-After header is not present for the concurrent limit response.
While these are very strict limits, you are able to ask for large amounts of data in a single request if you are using multiple items with larger date ranges. So it is well suited for anyone wanting to gather large amounts of historical adherence data across several months or several different management units at once. It also has some advantages for requests with smaller individual items, because we often can optimize better when compared to individual management unit requests. So when requesting smaller items in a bulk request, you may find that the request completes faster than individual management unit requests would have, but the stricter limits can slow down your throughput.
For anyone that may find this in the future... It looks like both the /api/v2/workforcemanagement/managementunits/{managementUnitId}/historicaladherencequery API and the /api/v2/workforcemanagement/adherence/historical/bulk/ API only allow for 32 days max (without exceptions). So the only difference between these APIs is that the bulk allows for up to 6 items at a time and it also doesn't include the same data. It's mostly the same data.
I just wanted to clarify one thing about the difference between the 2 APIs. The bulk API has no limitations on exceptions. This means you can ask for exceptions to be included regardless of the number of days or users.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.