Management is the day-to-day operation of an API in production. Plans, rate limits, keys, and access all get administered here, usually through a gateway. Solid management is what lets me offer an API to thousands of consumers without it becoming chaos.
Management
Production
Stop 17
Policies at this stop
API Mocking (CI/CD)
Require that every API can be mocked directly from its contract so consumers and downstream teams can build against it before the implementation is finished. I lean on mocking because it is what ma...
Contract Testing (CI/CD)
Require that every API is tested against its own contract in the CI/CD pipeline so the running service can never quietly drift from the OpenAPI it publishes. I insist on contract testing because a ...
Linting (CI/CD)
Require that every API contract is automatically linted against our design and governance rules on each commit, so standards are enforced by machines rather than by memory and goodwill. I love lint...
Schema Registry (CI/CD)
Require that the schemas an API relies on are published to a shared schema registry and validated against it in CI/CD, so the shapes of our data are versioned, discoverable, and compatible. I want ...
Environments
The environments for development, staging, or production environments should be available to manually or automatically working with an API in any environment, providing a machine-readable way for n...
Gateways
All APIs are made available via a designated gateway for the company, domain, line of business, or team, ensuring that all APIs have access to shared authentication, rate limits, service compositio...
MCP Server Provided
I require that an API of consequence exposes a Model Context Protocol server so that agents can discover its capabilities and invoke them through a standard, well-understood interface rather than a...
Caching (Operations)
Require that every read-heavy API sets explicit HTTP caching headers, so I want Cache-Control, ETag, and Last-Modified in play with sensible max-age and validation behavior spelled out in the contr...
Error Handling (Operations)
Require that every API returns standardized, informative errors, so I want a consistent error envelope, a correct HTTP status code, a machine-readable code, and a human-readable message on every fa...
Filtering & Sorting (Operations)
Require that collection endpoints offer consistent, documented filtering and sorting, so I want a shared convention for query parameters, allowed fields, operators, and sort order applied the same ...
Health Checks (Operations)
Require that every API exposes a standard health check endpoint, so I want a predictable path that reports liveness and readiness along with the status of critical dependencies. I insist on this be...
Logging (Operations)
Require that every API produces structured, correlated logs for each request, so I want a consistent log schema, a correlation or trace identifier carried through, and clear rules about what gets c...
Monitoring (Operations)
Require that every API is actively monitored for availability, latency, error rates, and traffic, so I want the golden signals collected, dashboarded, and wired to alerts before an API ever reaches...
Pagination (Operations)
Require that every endpoint returning a collection paginates its results using a single, consistent strategy, so I want a documented approach, whether cursor or offset, with clear page-size limits ...
Rate Limiting (Operations)
Require that every API enforces rate limits and communicates them clearly, so I want defined quotas per consumer, standard headers that report remaining budget, and a proper 429 with a Retry-After ...
Rate Limits
Providing details of rate limits being applied as part of each plan, and what is available to consumers as part of their application usage.
