# api rate limit hit mid vendor portal bid status poll causing failed run: how to fix it

Tight polling loops hit portal rate limits fast. Poll on a backoff schedule, cache the last status, and stop polling once the status reaches a terminal state.

```text
api rate limit hit mid vendor portal bid status poll causing failed run
```

## When to use this skill
- Bid status polling fails on rate limits
- Agent polls the portal hundreds of times

## When not to use this skill
- Status returns wrong data (a data issue)
- Portal blocks the agent entirely (an access issue)

## Tool compatibility
Agent bid status polling. Related area: monitoring and observability.

Related area: proposal automation and agent-assisted RFP workflows.

Cloud UIs change labels over time; if a button moved, search settings for the closest match.

## Before you start
- Sign in to the tool and keep one tab open so sessions stay clean
- Copy the exact error text and note the time it happened
- Set aside 15 to 20 minutes; most of these resolve in a single pass

## Quick diagnosis
Make sure this is the right skill before you invest the 15 minutes.
- If you are dealing with bid status polling fails on rate limits, start at step 1 below.
- If instead status returns wrong data (a data issue), stop here; you need a different skill.
- If neither quite matches, compare your screen against the verbatim error block at the top; that block is exactly what this skill covers.

## Fix it in steps
### 1. Set a backoff poll schedule

```
Poll every 10 minutes, doubling the interval after each unchanged status.
```
Expected: Expected: poll rate drops as the wait lengthens.

### 2. Cache the last status

```
Store the most recent status between polls.
```
Expected: Expected: no duplicate processing of the same status.

### 3. Stop at terminal states

```
End polling when the status reads awarded, rejected, or closed.
```
Expected: Expected: run exits instead of polling forever.

### 4. Alert on change

```
Notify the human only when the status actually changes.
```
Expected: Expected: one alert per real transition.

## Confirm each step worked
Run through this checklist before moving on. If a check fails, redo that step instead of pushing ahead.
- Step 1 (set a backoff poll schedule): Expected: expected: poll rate drops as the wait lengthens.
- Step 2 (cache the last status): Expected: expected: no duplicate processing of the same status.
- Step 3 (stop at terminal states): Expected: expected: run exits instead of polling forever.
- Step 4 (alert on change): Expected: expected: one alert per real transition.

## Quick recap
1. Set a backoff poll schedule
2. Cache the last status
3. Stop at terminal states
4. Alert on change

## Still stuck?
Gather three things: the exact error text, the time it happened, and what changed just before it broke.
Check the vendor status page for an active incident. Then open a support ticket with those three things;
it cuts the back-and-forth in half. For agent runs, attach the last 50 lines of the agent log too,
since the loop or timeout signature in the log usually names the cause.

## Variant phrasings
### agent bid status poll rate limit
Backoff polling fixes it. If this matches what you saw, the steps above apply as written.

### vendor portal poll 429 agent
Cache and terminal states help. If this matches what you saw, the steps above apply as written.

## Why it happens
Bid statuses change rarely, so constant polling wastes the rate budget on identical answers. Backoff polling spends budget where it matters: catching the transition.

## Edge cases
- Portals publish status change timelines; align polling to them
- A status that never reaches terminal may mean the bid was withdrawn; check manually
- Log every poll so the rate usage is auditable

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_F-8UDeL7SZ-Zid3RjXQYBw