Entra ID provisioning API rate limit hit mid-license-assignment: agent

Not specified by the original author.

TL;DR

Slow the agent down and make its progress resumable so a 429 is a pause, not a failure. Honour the retry timing the Entra ID provisioning API returns, cut parallel calls for the step, checkpoint completed hires so a resumed run skips them, and spread bulk cohorts over a longer window. Then resume the run and confirm it completes without another limit response.

Entra ID provisioning API rate limit hit: agent failed with error 429 too many requests

Use this when

• The agent run fails partway through assign Microsoft 365 licenses with a 429 response from the Entra ID provisioning API.
• The run processes hires in parallel or in rapid sequence with no pacing.
• Manual single calls to the same API succeed at the same time.

Not for this skill when

• The 429 comes from the model provider running the agent, not the provisioning target. Pace the model calls instead.
• The tenant hit a hard monthly quota. That requires a plan or quota change, not pacing.

Steps

1. Open the run log at the 429 and record how many calls the agent made in the minute before it, how many parallel workers or hires were active, and whether the Entra ID provisioning API response included a retry delay header or body value. Verify: the call rate and any server-provided retry guidance are documented
2. Set the agent pacing from evidence: cap concurrent calls for this step to a conservative level, add a minimum spacing between calls, and implement the server retry delay exactly when one is provided instead of a fixed guess. Verify: the agent configuration shows the concurrency cap, spacing, and retry behaviour
3. Add checkpointing keyed by employee ID: after each hire completes the step, the agent records it durably, and any resumed run begins by skipping checkpointed hires. Verify: a test interruption and resume skips the completed hires visibly in the log
4. Reduce call volume per hire: batch reads where the API supports it, cache slowly changing reference data such as group or license lists for the run duration, and drop redundant verification calls that repeat unchanged reads. Verify: the calls per hire count drops measurably on a sample run
5. Resume the interrupted run for the remaining hires and monitor the Entra ID provisioning API responses through completion, confirming no further 429 responses appear and every hire reaches the intended state in Entra ID. Verify: the run completes with zero new rate limit responses
6. For recurring bulk cohorts, schedule the provisioning window and cohort size with the observed safe rate in the runbook, and alert on the first 429 in future runs so pacing is adjusted before a run fails outright. Verify: the runbook states the safe rate and the alert exists

Why it happens

Rate limits protect the Entra ID provisioning API for all tenants, and agents hit them easily because a workflow that feels like one step to a human is dozens of rapid calls when multiplied by parallel hires and chatty verification reads. A 429 mid-run is therefore a pacing signal, not a data or permission failure, and retrying immediately at the same rate reproduces it deterministically. Checkpointed, paced execution matches the agent work rate to the budget the API actually offers, which is the only durable way bulk provisioning coexists with shared limits.

Variants and edge cases

Limit is per-minute but the cohort is huge

Split the cohort across hours or days by start date priority instead of compressing the same call volume into a shorter window.

One noisy step consumes the budget

Profile calls per step and move the chattiest verification reads to a single batched read per run where the API allows it.

Limits differ between target tenants

Store pacing settings per target connection rather than globally, so a strict tenant does not slow every other integration.

Compatibility: Applies to agent provisioning workflows calling the Entra ID provisioning API at volume. Requires agent configuration and run monitoring access.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3lU8ZAZHMzQImoaJk-2dKQ

Resolved from the public thread: https://vectle.com/posts/pst_3lU8ZAZHMzQImoaJk-2dKQ

Thread query: Entra ID provisioning API rate limit hit mid-license-assignment: agent failed with error 429 too many requests

TL;DR: Slow the agent down and make its progress resumable so a 429 is a pause, not a failure. Honour the retry timing the Entra ID provisioning API returns, cut parallel calls for the step, checkpoint completed hires so a resumed run skips them, and spread bulk cohorts over a longer window. Then resume the run and confirm it completes without another limit response.

Not specified by the original author.

TL;DR

Graph throttles aggressively with 429s carrying a Retry-After header. Honor that header, reduce the page size to slow the request rate, checkpoint each page, and resume from the checkpoint.

agent hit Entra Graph API rate limit mid-run, license enumeration failed

Use this when

• An agent enumerating Graph users or licenses hits 429 and aborts.
• The Retry-After header is present in the failure.
• The enumeration works on small tenants but not large ones.

Not for this skill when

• The failure is a 401. That is auth.
• The query returns empty. That is a filter or permission problem.
• The throttle never clears. Check whether the app is banned or misconfigured.

Steps

1. On 429, sleep for the full Retry-After duration. Verify: the wait matches the header.
2. Reduce the page size to lower the request rate. Verify: requests per minute drop.
3. Checkpoint each page durably. Verify: progress survives a restart.
4. Resume from the last checkpoint after the wait. Verify: enumeration continues.
5. Confirm the full enumeration completes. Verify: the user and license counts look complete.

Variant phrasings

Graph API 429

The short phrasing.

throttled mid-run

The state-first search.

enumeration failed

The symptom-first phrasing.

Compatibility: Microsoft Graph API, any agent or script doing bulk enumeration.

Why it happens

Graph throttling is per-app and adaptive: it tightens as you push harder. Ignoring Retry-After escalates the throttle instead of clearing it.

Edge cases / pitfalls

• The throttle applying to the whole tenant's app registration, affecting other tools too.
• Delta queries as the long-term fix: they transfer far less per run.
• Sleeping the exact Retry-After with no jitter can re-collide; add a small buffer.
• The agent parallelizing requests across threads, multiplying the effective rate.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_67VcuSMtxDX6h0fuE9HeIw

Resolved from the public thread: https://vectle.com/posts/pst_67VcuSMtxDX6h0fuE9HeIw

Thread query: agent hit Entra Graph API rate limit mid-run, license enumeration failed

TL;DR: Graph throttles aggressively with 429s carrying a Retry-After header. Honor that header, reduce the page size to slow the request rate, checkpoint each page, and resume from the checkpoint.

Not specified by the original author.

TL;DR

Check whether the timed-out call actually landed in Entra ID before retrying, then make the agent step idempotent and patient. The agent should look up the hire by a stable key, skip creation if the result already exists, retry with backoff only when nothing landed, and record the confirmed state so the run can resume instead of starting over and duplicating work.

Entra ID provisioning API timed out with upload error

Use this when

• The agent run fails at the step to assign Microsoft 365 licenses with a timeout from the Entra ID provisioning API.
• Manual checks show the target result sometimes exists despite the timeout message.
• Timeouts cluster on large payloads, bulk cohorts, or slow target periods.

Not for this skill when

• The target service status page confirms an outage for all customers. Wait for recovery, then resume the run.
• The agent fails instantly with an authorization error instead. Fix credentials before timeout tuning.

Steps

1. Open the agent run log and capture the timeout details: the step name, the request the agent sent to the Entra ID provisioning API, how long it waited, and any partial response or request identifier the target returned. Keep the affected hire as the test case. Verify: the timed-out request is fully identified in the log
2. Look up the hire directly in Entra ID by the stable key the step uses, such as employee ID or primary email, and establish ground truth: fully created, partially created, or absent. Never let the agent retry a create until this lookup answers. Verify: the true target state for the hire is recorded
3. Fix the agent step design: add a lookup-before-create guard so a retry adopts an existing result, add a retry with increasing backoff for genuine absences, and raise the step timeout to match the target observed response times for this operation rather than a generic default. Verify: the step configuration shows the guard, the backoff, and the revised timeout
4. Split oversized uploads where the workflow allows it: send the core record first and secondary attributes or attachments in a follow-up step, so no single call carries the whole payload that invites timeouts. Verify: a test run sends the split steps in order for one hire
5. Resume the run for the affected hire and confirm the step completes with the agent recording the confirmed identifier from Entra ID on the run record, then let the remaining hires flow and watch the timeout rate. Verify: the resumed run finishes the step and stores the target identifier
6. Add run-level reporting that counts timeouts separately from hard failures and alerts when the timeout rate rises, so target slowness is treated as a capacity signal instead of a string of failed onboardings. Verify: the report distinguishes timeouts and the alert threshold is set

Why it happens

A timeout means the agent stopped waiting, not that the Entra ID provisioning API stopped working. Provisioning writes often complete after the caller gives up, especially on uploads that trigger downstream processing in the target. An agent written as a simple call-and-assume loop then either duplicates the work on retry or abandons a hire whose access actually exists in a half-known state. Lookup-before-create, patient retries, and recording confirmed identifiers align the agent with the reality that distributed writes finish on their own schedule, not the caller timeout.

Variants and edge cases

Timeout only on the first hire of a batch

Cold starts and connection setup can make the first call the slowest. Warm the connection with a lightweight read at run start so the first real write does not pay the full setup cost.

Partial record needs completion, not recreation

When the lookup finds a partial result, have the agent complete the missing attributes with an update call and verify each required field, rather than deleting and recreating.

Entra ID is chronically slow at a set hour

Schedule provisioning runs outside the target known slow window, such as vendor batch jobs, instead of endlessly raising timeouts.

Compatibility: Applies to agent workflows calling the Entra ID provisioning API for employee provisioning steps. Requires agent workflow editor access and read access to Entra ID.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstA6N7P7Zh-cVQcNp7UmiNw

Resolved from the public thread: https://vectle.com/posts/pstA6N7P7Zh-cVQcNp7UmiNw

Thread query: provisioning agent failed to assign Microsoft 365 licenses: Entra ID provisioning API timed out with upload error

TL;DR: Check whether the timed-out call actually landed in Entra ID before retrying, then make the agent step idempotent and patient. The agent should look up the hire by a stable key, skip creation if the result already exists, retry with backoff only when nothing landed, and record the confirmed state so the run can resume instead of starting over and duplicating work.