paulund

20. Pre-Release Checklist

20. Pre-Release Checklist

Run through this checklist before you promote any API version to production. Every item on this list has a corresponding section earlier in this guide — treat it as a final verification pass, not a first encounter with these concepts.

Documentation and Specification

  • OpenAPI specification is complete and accurately describes every endpoint, parameter, and response shape.
  • Request, success, and error examples are included for each endpoint.
  • The specification validates against the OpenAPI schema without errors.
  • A changelog entry has been written for this release.

Correctness and Consistency

  • Status codes are correct and consistent across all endpoints (see topic 4).
  • The error envelope is used for every error response, including validation errors (see topics 6 and 13).
  • Field naming follows the agreed convention throughout (see topic 8).
  • Datetime values are in UTC ISO 8601 with a trailing Z (see topic 9).
  • Pagination is present on every list endpoint with sensible defaults and a documented maximum (see topic 5).

Security

  • All endpoints are served over HTTPS.
  • Security headers (Strict-Transport-Security, X-Content-Type-Options) are set.
  • Authentication is enforced on every endpoint that requires it (see topic 10).
  • Input validation rejects malformed requests before they reach application logic (see topic 12).

Performance and Reliability

  • Rate limiting is active and the relevant headers are included in responses (see topic 11).
  • Caching headers (Cache-Control, ETag) are set on all cacheable GET endpoints (see topic 14).
  • Idempotency keys are supported on POST endpoints where duplicate creation would be harmful (see topic 15).

Testing

  • Automated tests cover the happy path for every endpoint.
  • Automated tests cover the expected failure paths (invalid input, missing auth, not found, rate limit exceeded).
  • Edge cases — empty collections, maximum pagination limits, concurrent requests — have been tested.

Observability

  • Every response includes a unique request or correlation ID (see topic 16).
  • Server-side logging captures errors with full context but does not expose stack traces in API responses.
  • Monitoring and alerting are configured for error rates and latency.