Other than the 100 calls per 10-second per access token, is there additional gates / hoops?
I seem to be getting 429 even when I request new access tokens every 99 calls.
I also seem to be getting 429 even when I dynamically create new PAT every 50 calls.
Some kind of burst limit?
Hello @David_Norris ,
What is the api call that you are making ?
This:
In my opinion the limit is per client ID. So, generating a new access token will not help you by pass the 429 response. What I usually do is wait for few (around 450 just be on safer side) milliseconds between each call
Each new PAT has it’s own client ID…so that’s why I’m not fully understanding the 429 that I’ve been getting. I’ve been generating new PATs, and therefore new client IDs, and using them…but still hit with 429. Also, I’ve included a 10 seconds wait if 429 is hit…but still, that doesn’t give me a fresh 100 calls quota for the next 10 seconds.
Something isn’t really spelt out there…what’s missing from the documentation?
It’s almost as if the reassignment certs async has an internal queue on the ISC side that needs to be cleared / flushed before I can make more calls to it.
Side note: 450ms wait per call is really not a performant solution, if you ask me. In my case, it’s an async call (a bunch of)…so it ought to be like, “Hey, here’s the stack of reassignments…deal / scale with it as you will”…end of calls.
Not sure why are you facing this issue. I have been running scripts that make hundreds of API calls with a wait between calls and never had any issue
Yeah, it is puzzling indeed.
This API initiates a task to reassign up to 500 identities or items in an identity campaign certification to another reviewer. The certification-tasks API can be used to get an updated status on the task and determine when the reassignment is complete.
Reviewers for this certification can also call this API.
Thanks, but I’m already aware of that from the documentation…plus that’s a task on the ISC side of things. There’s no mention that this will impact / affect the API rate control counter at all.
Think I’ve found the issue:
There appears to be an undocumented behaviour (at least unknown to me) with the async certification reassignment queue size. Once the queue size (pending certification tasks) has reached 10, it wouldn’t take any more…and would return a rather incorrect 429.
Assuming this observation is true, then the 429 is really a lie…because it’s queue size induce, and not rate / time induced.
Also noticing that the queue size allowance is not always 10. Sometimes, it’s 8, sometimes it’s 5. It’s a floating / managed queue length.
So here’s the other thing…production vs sandbox. It seems like production tenant is able to [handle / process] the [load / queue] way faster…which makes sense (but not documented, assuming the observation is correct). But at the same time, that seems to indicate sandbox isn’t suitable to be used for performance testing?
Does anyone know how true this observation is? Like, is sandbox’s performance meant to be less than that of production tenant?
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.