---
id: w7/m3/t005
title: "Render parity — 429 shape consistent across REST · GraphQL · MCP, vs Render's docs; dashboard handles 429"
worker: worker7
status: done
estimate: 30m
depends_on: [w7/m3/t003, w7/m3/t004]
---

## Objective

Standing closing check: the milestone's surface changes are consistent across every adapter — the 429 envelope, `Retry-After`, and cap errors carry the same fields/semantics on REST, GraphQL, and MCP; they match Render's documented contract (t001's capture); and the dashboard degrades gracefully on a 429 instead of breaking. Flag any drift as follow-up work rather than silently diverging.

## Context

- Standing closing task (`.claude/commands/pm.md` §Render parity); bex-api is one core with three adapters (docs/ADR006-bex-api.md).
- Render's contract as captured in docs/ADR006-bex-api.md §Rate limits (t001); Render REST spec marks 429s per endpoint.
- Dashboard: Apollo client + REST calls in `dashboard/` (see `dashboard/CLAUDE.md`) — check the Logs/Metrics/Services surfaces for unhandled 429s.
- Update docs/ADR018-render-parity.md: rate limiting merits a row (or a note in the relevant sections) with evidence pointers.

## Steps

1. Exercise each adapter past the limit; diff the three error shapes against each other and t001's capture.
2. Trip a 429 while browsing the dashboard; confirm sane UX (error toast/retry, no white screen) — file follow-ups for anything broken.
3. Sync docs/ADR018-render-parity.md with the new capability + evidence.

## Files

- `docs/ADR018-render-parity.md`
- (follow-up notes for any drift found — `w7/NNN.md` or `w5/NNN.md`)

## Acceptance criteria

- [ ] Three adapters return the same limit semantics; divergences from Render are documented deliberately
- [ ] Dashboard behaves sanely under 429 (or follow-up filed)
- [ ] Parity ledger updated with evidence pointers

## Out of scope

- Fixing dashboard 429 UX beyond a trivial patch (file to w5)
