When using the WFM APIS to get schedule details, forecasting and team numbers I am getting 429 errors being thrown even after 1 or 2 calls. This is with a fresh Oauth, is there something I should be looking for? Typically it is calls that start /api/v2/workforcemanagement/businessunits/ or /api/v2/workforcemanagement/managementunits/ that are affected .
All the other API calls I make to the analytics or users give me what the document says is available per min. The workforce management ones seem very random in their sending the 429 response.
{
"message": "Rate limit exceeded for endpoint: GET /v2/businessunits/{buId}/weeks/{weekDate}/schedules. Maximum number of requests allowed per minute is 60. Try again in 35 seconds",
"code": "too.many.requests",
"status": 429,
"contextId": "8f4d1228-5ee8-4ecc-8895-a70c550182d1",
"details": [],
"errors": []
}
This is very low compared to the rest but that's not the only problem. I see it says retry in 35 secs, but the header says
15 secs - if we follow that it then blocks us for 60 seconds
Paul -
It does look like there's a bug in setting the retry-after header incorrectly on the response. There is an upcoming change which will fix the retry after header going forward but that could be a few months out. (Note: I would recommend against attempting to parse the error message string to get the correct retry-after value as that will be changing as well when the fix is deployed. Error message text is not guaranteed not to change)
But I also want to try to address the root cause of why you're getting rate limited to begin with. Looking in the logs it appears that you may be looping through multiple weeks of schedules, one week at a time with no pause, which would very quickly hit the rate limit on any given route.
Rate limits are checked per user (or per oauth client, as applicable), per route. So it would be helpful to understand what you're attempting to accomplish here.
It's also worth noting that the schedule list route you're calling here (as well as the similar short term forecast list route) support passing recent for the {weekDate} path parameter, which will in most cases give you +/- 6 months of schedules (unless you have a very large number of schedules during that time period in which case the route is limited to returning 300). See the doc here for more details: GET /api/v2/workforcemanagement/businessunits/{businessUnitId}/weeks/{weekId}/schedules
If it would help, you could send me a private message with your code so perhaps we could suggest an alternative way to accomplish your goals?
I'm glad the /recent change helped out. Keep in mind the same 60/min/user request limit will also apply to the headcount forecast route, which may or may not affect you depending on how many schedules you have.
Given the previous value of retry-after was wrong, I'm guessing the decision was to stop providing it until we can provide it accurately. Let me confirm
I just confirmed. The value that was previously being supplied was bad data and so it was removed to prevent continuing to unintentionally mislead clients into incorrect behavior. The correct retry after value will be available per the timeline mentioned in the linked post.
In the meantime I'd recommend implementing an exponential back-off retry model when you receive a 429.
