Developer API Documentation Portal with Live Try-It Console

Every backend project needs documentation, yet most student APIs ship with a README paragraph and a Postman screenshot. Professional API docs are generated from a machine-readable spec, stay in sync with the code, and let developers execute calls without leaving the page. This project builds that experience from scratch: an OpenAPI-driven portal that renders endpoint pages (parameters, schemas, errors) from the spec file, a try-it console that sends live requests through a sandbox proxy and pretty-prints responses, syntax-highlighted samples in curl, Python and JavaScript, plus API key issuance with per-key usage tracking, a version switcher and a changelog. The demo API is a realistic orders/payments service so every example is executable.

1. The API's OpenAPI 3.1 YAML/JSON spec is the single source of truth; the portal parses it at build/startup into endpoint, schema and error models.
2. The docs renderer turns each endpoint model into a page: route, description, parameter tables, request/response examples and error tables.
3. The try-it console builds its form from the endpoint's parameter and schema definitions, so the console always matches the docs.
4. On send, the browser posts to the portal's sandbox proxy (never exposing the real API key to page JS in production mode); the proxy forwards to the sandbox API and returns status, headers and body.
5. Responses render with JSON syntax highlighting, timing and size; errors link straight into the error catalog.
6. API keys are issued per project/environment, stored hashed, with a usage counter incremented per proxied call and shown as monthly meters.
7. Publishing a new spec version snapshots the old one; the version switcher and changelog diff keep every version browsable.

Tech stack:

• Node.js + Express (portal + sandbox proxy)
• OpenAPI 3.1 (spec-driven rendering)
• Demo orders/payments API (sandbox target)
• PostgreSQL (keys, usage, versions)
• Redis (rate limiting, response cache)
• JWT (portal auth)
• highlight.js-style code rendering
• Docker + docker-compose

• [Spec-driven endpoint pages] Every endpoint page — method, path, parameters, request/response schemas, error codes — renders from a single OpenAPI 3.1 spec file.
• [Live try-it console] Fill in parameters and a JSON body, hit send, and see the real sandbox response with status code and timing.
• [Code samples] Copy-paste examples in curl, Python and JavaScript generated from the same spec, so docs and samples can't drift.
• [API key management] Issue, revoke and rotate sandbox/production keys with per-key monthly usage meters.
• [Version switcher] Multiple spec versions browsable side by side; breaking changes flagged in the changelog.
• [Error catalog] Every error code documented with cause and fix, linked from each endpoint's error table.
• [Full-text endpoint search] Jump to any endpoint, schema or error from the search bar.
• [Changelog] Dated, categorized API changes so integrators know what moved.

• Docs portal (spec renderer, search, version switcher, changelog, error catalog)
• Try-it console with sandbox proxy and response viewer
• Demo orders/payments API with realistic sandbox behavior
• API key management with usage meters
• Sample OpenAPI spec plus a guide to documenting your own API
• Project report PDF (spec-driven architecture, proxy design, key security, methodology, results)
• PPT presentation for final review
• Viva Q&A preparation document (OpenAPI, CORS/proxying, key hashing, idempotency)

• The try-it console calls a sandbox demo API; wiring it to a production API needs the deployer's credentials and CORS/proxy configuration, documented in the setup guide.
• Code samples are generated from the spec's examples — unusual hand-written flows still need manual sample authoring.
• The portal documents REST/JSON APIs; WebSocket or GraphQL APIs are future scope.
• Usage metering counts proxied console calls; direct-to-API traffic needs the API itself to report usage, documented as an integration point.
• The demo API's data is synthetic and resets periodically; it is not a payments backend.
• SDK generation (typed clients) is future scope — the build ships curl/Python/JS snippets.