Pin down the interface between two services
When two microservices talk, ambiguity is expensive: one team assumes a field is optional, the other makes it required, and the integration breaks in staging. An API contract removes that ambiguity by writing the interface down before the code exists. This builder generates a structured contract with schemas, error codes, an SLA, and a versioning policy.
How it works
You describe the endpoint and list the request and response fields with their types and required flags. The tool produces:
- Endpoint — method and path, plus the consumer and provider names.
- Request schema — a table of fields, and a sample JSON request built from your field definitions, using type-appropriate placeholder values.
- Response schema — the success body as a table and a sample JSON response.
- Error codes — the HTTP statuses the endpoint returns and what each means.
- SLA — latency and availability targets.
- Versioning policy — how breaking versus additive changes are handled.
Everything renders in your browser. The sample JSON is generated from your schema so it always matches the field list.
Tips and example
Keep contracts additive. Adding an optional field is safe; removing or renaming one is a breaking change that needs a new major version. State this explicitly so neither team is surprised.
Pick realistic SLA numbers your service can actually hit, for example p95 latency under 200ms and 99.9% availability, then design consumer timeouts above that with a retry budget. Document the failure mode too: a 503 with Retry-After is far kinder to consumers than a silent hang.
Treat the generated sample request and response as the seed for a consumer-driven contract test. Capturing the expected shapes in CI means either side drifting from the contract fails the build instead of an integration in production.