Schemas
Request and Response Patterns
Reusable request and response rules for developers adding or consuming API routes.
First created Last updated
End-to-end developer runbook
- Step 1 - Confirm the API area: Identify the product area, route module, endpoint path, and consumer before writing or calling code.
- Step 2 - Read the endpoint contract: Check method, auth, parameters, response, errors, side effects, and related docs.
- Step 3 - Prepare authentication and input: Use the right session, bearer token, webhook secret, or internal header. Validate body and query data before sending it.
- Step 4 - Make the request: Call the endpoint from the correct origin and environment. Keep credentials and secrets out of logs.
- Step 5 - Verify response, side effects, and records: Confirm status code, response shape, database records, external side effects, and audit evidence.
- Step 6 - Add tests, docs, and handoff notes: Update route inventory, consumer notes, and certification checks before depending on the change.
Pattern checklist
- Action 1 - Use explicit methods: Keep reads as
GET, creates asPOST, partial updates asPATCH, replacements asPUT, and removals asDELETEwhen possible. - Action 2 - Validate body before use: Parse JSON or form data once and reject invalid input with a clear status and
errormessage. - Action 3 - Return stable keys: Consumers should not depend on incidental Supabase column names unless documented.
- Action 4 - Include IDs for changed records: Mutation responses should let callers verify what changed.
- Action 5 - Keep binary responses obvious: Image proxy, downloads, and release routes need content type and cache notes.
Checkpoint list
- Checkpoint 1 - Example request exists: Docs show a realistic request.
- Checkpoint 2 - Example response exists: Docs show success and failure shapes.
- Checkpoint 3 - Unknowns are labelled: Missing proof is marked
Unknown from source, not guessed.