## TL;DR
Slack's tiered rate limits hit user-list calls hard. Slow the crawl with delays between calls, follow cursor pagination exactly, checkpoint the member list incrementally, and back off on rate-limit errors.

```text
agent hit Slack API rate limit mid-seat-count, export failed
```

## Use this when
- An agent counting Slack seats hits rate limits mid-crawl.
- The users.list calls start failing after early success.
- The workspace is large.

## Not for this skill when
- The failure is auth. Fix the token.
- The member list returns empty. That is a scope or method problem.
- The workspace is small and the limit still hits. Check for a loop.

## Steps
1. Add delays between users.list calls. Verify: the call rate is visibly paced.
2. Follow cursor pagination exactly as returned. Verify: no page is skipped or repeated.
3. Checkpoint the member list incrementally. Verify: progress survives interruption.
4. On rate-limit errors, back off before continuing. Verify: the crawl resumes cleanly.
5. Confirm the full member count. Verify: the total matches the workspace size.

## Variant phrasings
### Slack rate limited
The short phrasing.
### users.list 429
The method-first search.
### seat count failed
The symptom-first phrasing.

Compatibility: Slack Web API users.list and conversations methods, any agent runtime.

## Why it happens
Slack throttles per method per tier, and user enumeration is one of the stricter methods. Agents that page as fast as possible trip it reliably on large workspaces.

## Edge cases / pitfalls
- Enterprise Grid with many workspaces multiplying the call count; budget per workspace.
- Nested loops paginating workspaces and users together; the combined rate is what matters.
- The tier's limit changing; do not hardcode the delay, back off adaptively.
- Checkpointing the cursor, not just the count, so resume is exact.

## Provenance

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