Skip to content

Add docs/API_ERRORS.md listing every stable error code #698

Description

@Baskarayelu

Summary

Description, HTTP status, and typical remediation.

Background

We rely on this information internally but it is currently tribal knowledge. Writing it down lets reviewers verify behaviour against the documented intent, lets new contributors get productive without reading every commit, and lets the support team answer common questions without paging an engineer.

Acceptance criteria

  • The change matches the summary above.
  • The new document is linked from at least one existing top-level doc (README or docs/README).
  • Examples in the document compile / run if applicable.
  • Lint, type-check, and tests all pass locally.
  • PR description references this issue with Closes #<this-issue>.

Implementation hints

  • Audience: pick one (contributor / operator / downstream integrator) and write for them; do not try to address all three in the same doc.
  • Prefer concrete examples over abstract definitions. Show a real entrypoint, request, or output rather than foo() placeholders.
  • Cross-link from the README and from any related doc; orphaned docs rot fastest.
  • Where the project ships generated docs (rustdoc, JSDoc, OpenAPI), keep this new content discoverable from the same starting point.

Repo-specific notes

  • Run npx tsc --noEmit, npm test, and the security:scan / sbom:check scripts locally before pushing.
  • Any new request or response shape must have a matching Zod schema and a regenerated OpenAPI entry.
  • New env vars must be added to .env.example and to the relevant deployment doc.

Out of scope

  • Unrelated refactors in adjacent files.
  • Stylistic-only changes (formatting, renaming) that are not required by the fix.
  • Anything beyond the acceptance criteria above; surface follow-ups as separate issues.

How to claim and submit

  1. Comment on this issue saying you'd like to take it on; wait for a maintainer to assign you (avoids duplicated effort).
  2. Open a PR that references this issue (Closes #<this-issue>).
  3. Make sure CI is green and request review from a CODEOWNERS maintainer.
  4. PRs that close this issue and pass review may qualify for a reward — see the MAYBE REWARDED label and the FWC26 campaign page.

Category: documentation  ·  Campaign: GrantFox OSS · Official Campaign | FWC26 · Maybe Rewarded

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions