Slack SCIM deprovision failed" rate limited 429
Fixes Slack SCIM deprovisioning that fails with 429 rate limiting. Use when SCIM calls to Slack return 429. Not for permission or data blocks.
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
Slack SCIM deprovision failed: 429 Too Many RequestsSteps
- Confirm the 429 in the SCIM client logs and note the Retry-After header if present. Expected: the throttling confirmed with a suggested wait.
- Pause the deprovision queue and retry the failed operations with exponential backoff, honoring Retry-After. Expected: retries spaced out.
- Reduce concurrency: process deprovisions sequentially or in small batches instead of parallel bursts. Expected: request rate under the limit.
- 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