## TL;DR
Salesforce REST limits are per-org per-hour and agents burn through them fast. Switch large reads to the Bulk API, pace the remaining REST calls, checkpoint after each batch, and resume from the checkpoint on limit errors.

```text
agent hit Salesforce API rate limit mid-audit, run failed
```

## Use this when
- An agent auditing Salesforce hits API limit errors mid-run.
- The audit works on small orgs but fails on large ones.
- The error mentions the hourly or daily call limit.

## Not for this skill when
- The failure is a login error. That is auth.
- The failure is a permission error. That is sharing or profile config.
- The org has limit headroom but the agent still fails. Check for a runaway loop.

## Steps
1. Switch large data pulls to the Bulk API. Verify: the job-based pull starts.
2. Pace remaining REST calls within the hourly budget. Verify: the call rate stays under the limit.
3. Checkpoint after each batch durably. Verify: progress survives interruption.
4. On limit errors, wait out the window and resume from the checkpoint. Verify: the resume continues, not restarts.
5. Confirm the audit completes. Verify: the data covers the full org.

## Variant phrasings
### Salesforce 429 agent
The short phrasing.
### API limits audit
The cause-first search.
### bulk API
The solution-first phrasing.

Compatibility: Salesforce REST and Bulk APIs, any agent runtime.

## Why it happens
REST call limits are tight by design, and the Bulk API is the intended path for large reads. Agents default to REST for everything and hit the wall.

## Edge cases / pitfalls
- Concurrent jobs sharing the org's limit; coordinate or schedule apart.
- The agent's retry storm on limit errors consuming the next window too.
- Bulk API jobs also having limits; batch sensibly.
- The limit resetting hourly: a patient resume beats a clever workaround.

## Provenance

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