---
id: w7/m5/t005
title: Render parity — ipAllowList consistent across REST · GraphQL · MCP + dashboard, vs Render's KV Networking
worker: worker7
status: done
estimate: 30m
depends_on: [w7/m5/t004]
---

## Objective

Confirm the `ipAllowList` change is consistent across every surface it exposes and matches Render's managed Key Value Networking control — same field name, `[]string` CIDR shape, create/update semantics, and error shapes — flagging any drift as follow-up rather than silently diverging.

## Context

- bex-api is meant to be Render-compatible (`docs/ADR006-bex-api.md`, "one core, three adapters"); `docs/ADR018-render-parity.md` Key Value row is the ledger to update.
- Compare against: Render's KV/Redis Networking allowlist, and bex's own managed-Postgres `ipAllowList` (the internal consistency anchor).

## Steps

1. Diff `ipAllowList` handling across `keyvalue/{rest,graphql,mcp}.go` + the dashboard: same field name, shape, validation, error envelope on all four.
2. Compare with Render's KV Networking control and with bex's Postgres allowlist; note any conscious divergence.
3. Update the `docs/ADR018-render-parity.md` Key Value row — remove `ipAllowList` from the "omitted" list; record what shipped and any residual divergence.

## Files

- `docs/ADR018-render-parity.md`
- (audit only) `lego/backend/internal/keyvalue/{rest,graphql,mcp}.go`, dashboard KV route

## Acceptance criteria

- [ ] `ipAllowList` field name/shape/semantics/error shape are consistent across REST, GraphQL, MCP, and the dashboard.
- [ ] The parity ledger's KV row reflects `ipAllowList` as shipped; any divergence from Render is documented, not silent.

## Out of scope

- New functionality (implementation is t001–t004).
