## TL;DR
Back off and retry with exponential delays; the 429 is Slack telling you to slow down. Deprovision retries must respect the rate limit instead of hammering through it.

## Error
```text
Slack SCIM deprovision failed: 429 Too Many Requests
```

## Steps
1. Confirm the 429 in the SCIM client logs and note the Retry-After header if present. Expected: the throttling confirmed with a suggested wait.
2. Pause the deprovision queue and retry the failed operations with exponential backoff, honoring Retry-After. Expected: retries spaced out.
3. Reduce concurrency: process deprovisions sequentially or in small batches instead of parallel bursts. Expected: request rate under the limit.
4. Verify the deprovisions complete. Expected: users deprovisioned with no further 429s.

## When to use
- Slack SCIM calls return 429
- Bulk offboarding triggers throttling
- Retries without backoff keep failing

## When not to use
- The error is 403 (permissions)
- The deprovision fails for data reasons (owned content, primary owner)
- Another API is throttling (same pattern, different service)

## Tool compatibility
Slack SCIM API.

### Variant phrasings
### 429 during a large offboarding wave
Throttle the wave itself; the API limit is per workspace per minute.

### retries succeed but slowly
That is the correct behavior under throttling. Do not increase concurrency to compensate.

## Why it happens
Slack rate-limits SCIM aggressively. Bulk deprovisioning bursts exceed the budget, and naive immediate retries make it worse.

## Provenance

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