Add a note about exponential backoff

[pedromcunha]

No description provided.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
unevenlabs	🟢 Ready	View Preview	Aug 17, 2026, 9:36 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[github-actions]

Claude finished @pedromcunha's task in 2m 2s —— View job

---

Code review

• Read PR diff and changed file
• Check against AGENTS.md style guide
• Post review

The addition is correct and fills a real gap — references/api/api-keys.mdx:60 already promises this page explains "how to recover from 429 responses", and until now the page only covered prevention. Five things worth considering before merge, none blocking.

---

1. No Retry-After guidance — verify before merging. references/api/changelog.mdx:34 calls out that GET /requests/v2's 429 body is "distinct from the generic rate-limit body used by every other endpoint. No Retry-After header or field is emitted" — and migrating-to-requests-v3.mdx:61 repeats it as a notable exception. That framing strongly implies the generic 429 does carry Retry-After. If it does, blind exponential backoff is the wrong first instruction — readers should honor Retry-After when present and fall back to backoff when it isn't. Fix this →

2. Placement buries it. ## Optimize your request workflow is framed entirely around prevention ("Most integrations that reach a limit are sending requests they don't need"), and the intro at line 6 enumerates the page's three moves — optimize, switch to push, ask for an increase — without mentioning recovery. Recovering from a 429 is a different concern, and as the last paragraph of the prevention section it has no anchor for api-keys.mdx to deep-link to. A short ## Recover from a 429 section right after the intro would match how the rest of the page is organized (§3.3a → feature-guide shape) and give the inbound links a target. Fix this →

3. No concrete numbers. AGENTS.md §2.4 asks for concrete numbers when available, and the neighboring webhooks.mdx:113 does exactly that ("up to 10 retries with exponential backoff"). "An exponential backoff" leaves the reader to guess the starting delay. It matters here: default limits are per-minute windows (50/min on /quote), so a backoff that starts at 100 ms and caps at 2 s will exhaust its retries well inside the window that's still rejecting. A starting delay, cap, retry ceiling, and jitter would make this actionable. Fix this →

4. Wording. "hammering the API" is informal for the Stripe-adjacent register in §2.4, and the idiom is "retry with exponential backoff", not "after an exponential backoff". The second sentence also only restates the first. Suggested:

If you receive a 429, retry with exponential backoff rather than immediately — an immediate retry lands in the same window and fails again.

Fix this →

5. Minor — overlapping guidance. handling-errors.mdx already tells readers to "Retry with backoff" for transient 503s. Not a conflict, but a cross-link between the two pages would keep retry guidance discoverable from either entry point. Fix this →

---

Style guide compliance: frontmatter unchanged and valid (§2.1), heading levels untouched (§2.2), active voice and reader-as-"you" (§2.3), paragraph is 2 sentences (§2.10), 429 correctly backticked as a code value (§2.9), placed before the --- separator so it stays inside its section (§2.5). No docs.json nav change needed. Only §2.4 (tone, concrete numbers) has issues, covered above.

I reviewed only — no changes pushed. Item 1 is the one I'd resolve before merging, since it's a question of factual completeness rather than style.
· fix/rate-limit-backoff

[greptile-apps]

Greptile Summary

This change adds guidance for API integrators to use exponential backoff after receiving an HTTP 429 response, complementing the existing advice to reduce unnecessary requests and replace status polling with webhooks or websockets.

The proposed concern that the guidance must instruct users to honor Retry-After was disproved. Relay’s documented GET /requests/v2 429 contract states that it does not emit a Retry-After header, so the documentation does not omit a Relay-provided retry delay.

Confidence Score: 5/5

Safe to merge: the published retry guidance matches the checked Relay rate-limit contract.

The changed guidance was compared with the documented 429 response contract and live endpoint behavior. The contract confirms that the relevant endpoint does not provide a Retry-After header, and no actionable defect remains.

Files Needing Attention: No files need changes.

T-Rex Logs

What T-Rex did

• I ran a 120-request probe against Relay's live GET /requests/v2 and observed HTTP 200 responses with no Retry-After header, indicating the rate limit was not reached in this environment.
• I performed an unauthenticated request to GET /requests/v3 and observed HTTP 400 with the message that the x-api-key header is required.
• I checked Relay's documented 429 contract for GET /requests/v2 and confirmed that no Retry-After header is emitted on 429.
• I reviewed how the absence of a Retry-After header aligns with the contract and noted that exponential-backoff guidance is a refinement rather than a requirement, so it does not imply a Relay retry directive.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "Add a note about exponential backoff" | Re-trigger Greptile}