API Routes & Validation Rules: The Newer Domains
Env values and DB structure were never the whole picture — a service's API contract and the validation rules behind its data are just as easy to break silently. Two more domains share the exact same spine: one change, one notification, explicit approval before anything counts as "in sync."
API routes: owned by one service, consumed by others
Unlike an Env Master or DB Master, an API route isn't a workspace-wide shared thing — it's owned by whichever service defines it, and its url + method is the governed value. Two other services relate to that route completely differently, and OneEnv keeps them visually and functionally distinct rather than collapsing them into one "dependency" concept:
| Inherited (read-only) | Owned, tracks as source |
|---|---|
| A synced copy of someone else's route — status only, nothing to run | Your own route, whose url is copied in from the source when approved |
| "Inherit API Route" in the UI | "Inherit API Route" sets the Source; a separate "Add dependency" is purely documentation |
| Diverges on reject, resyncs on approve | Same in_sync / pending / diverged lifecycle, plus the url actually moves |
A service can also just document that its route depends on another one — no source tracking, no sync, purely an FYI note an approver sees on the notification ("this route also references what's changing, check it manually"). Three different relationships, three different guarantees, and the notification card says exactly which one applies so nobody mistakes an informational note for a promise that something will update itself.
The contract goes deeper than url + method now: a route's request fields are governed domain objects too. Adding, renaming, or removing a field stages a branch change exactly like a url edit — because a consumer breaks just as hard on a renamed body field as on a moved endpoint. A field can map to a real governed DB column (inheriting its validation) or carry a validation rule of its own, and routes can map onto the workspace's error-code catalog so "what can this return" is documented next to "what does it take."
Validation rules answer to two audiences at once
A Validation Master is a reusable rule — a regex or one of ten predefined patterns like email or UUID — and it can be attached to a DB column, inherited directly by a service, or both simultaneously. Changing the rule has to reach both:
Editing a route's url/method, a request field, or a validation rule doesn't notify immediately, either — it's staged as a change on a Branch first, the same as an env value edit. Nothing goes out until that branch is deliberately submitted for a single review and merged — env, API, validation, and DB changes can all ride on the same branch, reviewed together as one decision, before any of them becomes someone else's per-service approval checklist. A tightened validation rule is one of the signals the impact scorer treats as a breaking change, so it arrives flagged, not buried.