## TL;DR
The polling loop hammered the API until Salesloft suspended the key, and the missing Retry-After header is not permission to retry immediately. Stop all traffic, implement backoff with jitter plus a default cool-down when the header is absent, request reinstatement, and replace polling with webhooks.

```text
salesloft 429 'Too Many Requests' with no retry-after  -  agent's polling loop got the API key suspended
```

## Steps
1. Kill the polling loop completely. Every request while suspended digs the hole deeper.
   Expected: zero Salesloft traffic from the agent.
2. Check the suspension notice or support channel for the reinstatement path and follow it. This usually needs a human request explaining the fix.
   Expected: you know exactly what Salesloft needs to unsuspend the key.
3. Rewrite the polling logic before anything resumes: on any 429, back off exponentially with jitter, and when no Retry-After header is present, default to a conservative cool-down (minutes, not seconds) before the next attempt.
   Expected: the agent can never machine-gun the API again.
4. Better yet, replace the polling loop with webhooks for the events the agent was polling for. Webhooks do not consume rate-limit budget.
   Expected: the agent learns about changes without any polling traffic.
5. Only after reinstatement, resume with the new backoff and a per-minute request cap well under the published limits, and monitor 429 counts as a health metric.
   Expected: steady traffic with zero 429s.

## Use this when
- 429s arrive with no Retry-After header and the agent keeps polling.
- The API key or account got suspended after a rate-limit episode.
- The agent polls an endpoint on a fixed short interval.

## Not for this skill when
- The 429s carry Retry-After headers (follow the header; that is a different skill).
- The suspension came from a terms violation rather than traffic volume.
- The rate limits belong to a different platform.

## Variant phrasings
- "salesloft api key suspended too many requests"
- "salesloft 429 no retry after header polling"
- "salesloft polling loop suspended account"

## Why it happens
A tight polling loop treats "no Retry-After" as "retry now," which is the exact opposite of what the server wants. Repeated 429s signal an abusive client, so Salesloft escalates to suspension. Polling is also the wrong pattern here: it burns quota to ask "anything new?" when webhooks would push the answer for free.

## Edge cases
- Reinstatement can take a business day or more. Queue the agent's work so nothing is lost while waiting.
- Multiple agents sharing one key multiply the traffic. Give each poller its own budget or consolidate to one.
- After reinstatement, limits may be temporarily lower. Keep the conservative cap until traffic is clean for a week.

## Provenance

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