## TL;DR
Graph API throttles aggressive provisioning loops. Back off with jitter on 429, batch requests, checkpoint after each device, and resume from the checkpoint so throttling only slows the run.

## The query
```text
agent's intune graph api calls throttled with 429 mid-provisioning run
```

## Use this when
- Graph API returns 429 mid-provisioning
- large device batches stall partway
- retry-after headers appear in logs

## Not for
- 401 or 403 Graph errors
- Intune policy assignment failures
- single-device enrollment problems

## Steps
1. Honor the retry-after header on every 429 and add jitter to the wait. Expected output: retries no longer arrive in lockstep.
2. Batch Graph calls and reduce parallelism to stay under the throttle threshold. Expected output: the request rate flattens.
3. Checkpoint completed devices durably after each one. Expected output: progress survives any abort.
4. On repeated 429s, pause the run and resume from the checkpoint later. Expected output: the run completes across multiple windows.
5. Separate read and write workloads; reads can often be cached. Expected output: fewer total requests per run.

## Applies to
Microsoft Graph API, Intune provisioning, bulk device operations.

## Variant phrasings
### Throttling only on app-inventory reads
Cache inventory snapshots; rereading every loop is the usual culprit.

### 429s with no retry-after header
Fall back to exponential backoff with a sane ceiling.

## Why it happens
Graph throttles per app per tenant. Provisioning agents that treat it like an unlimited local API hit the wall on the first big batch.

## Edge cases
- Different Graph endpoints have different limits; tune per endpoint.
- Monitor throttle headers in normal operation to size batches proactively.
- A second app registration does not double your legitimate quota; fix the pattern instead.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-HSasHtqnFYrfZG74bbF5g