# onboarding agent failed okta api 429 mid batch deprovision run

## TL;DR
The agent treated Okta's rate limit as a fatal error and abandoned the batch with no record of progress. Stop the run, checkpoint which users were already deprovisioned, add handling that reads Okta's rate-limit headers and backs off until reset, shrink the batch size, and resume from the checkpoint. Verify every target user ends deprovisioned.

```text
onboarding agent failed okta api 429 mid batch deprovision run
```

## Use this when

- An onboarding agent's Okta batch run dies partway with 429 errors
- Some users in the batch are deprovisioned and others are not
- Re-running the batch double-processes users

## Not for this skill when

- 429s from non-Okta APIs (fix that API's limits)
- Okta 403 permission errors (credentials or scopes, not rate)
- Single-user deprovisioning failures (not a batch problem)

## Steps

### Step 1: Stop and checkpoint

Halt the agent and record exactly which users were already deprovisioned, from Okta's logs not the agent's memory. Expected: a definitive done-list to resume from.

### Step 2: Add rate-limit handling

Make the Okta client read the rate-limit headers, sleep until the reset window on 429, and retry with backoff. Expected: the client slows down instead of dying.

### Step 3: Shrink batch size and concurrency

Reduce parallel calls and batch sizes to stay comfortably under Okta's per-endpoint limits. Expected: the run stays under the limit for its whole duration.

### Step 4: Resume from the checkpoint

Restart the run skipping already-deprovisioned users. Expected: every remaining user is processed exactly once.

### Step 5: Verify the full batch

Confirm each target user shows deprovisioned in Okta. Expected: zero users left in a half-done state.

### Step 6: Make all batch runs resumable

Persist progress after each user so any future failure resumes cleanly. Expected: the next interruption is a pause, not a disaster.

## Tool compatibility

Okta API rate limits; batch deprovisioning agents; checkpoint and resume patterns for long runs.

## Variant phrasings

### Variant 1

okta api 429 batch deprovision rate limit

### Variant 2

okta rate limit headers backoff retry

### Variant 3

batch okta user deprovision failed halfway resume

## Why it happens

Okta enforces rate limits per endpoint across the whole organization, and batch jobs are the classic way to discover them: everything works in testing with ten users and collapses at five hundred. The 429 itself is recoverable, Okta even tells you when to retry, but agents typically treat any error as fatal and, worse, keep no record of how far they got. The result is a half-deprovisioned batch that cannot be safely re-run because the agent cannot tell done from pending. The fix has two halves that must ship together: respect the limit (backoff, smaller batches), and checkpoint progress so any failure, rate limit or otherwise, resumes instead of restarting.

## Edge cases / pitfalls

- Different Okta endpoints have different limits; the system log endpoint is stricter than most.
- The rate-limit bucket is shared org-wide; another integration's burst can cause your 429s.
- Okta's limits are per minute windows; a fixed sleep is cruder than reading the reset header, use the header.

## Provenance

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