API services
Services other systems depend on, where contracts must hold.
An API is a promise to software you do not control. Once something is consuming an endpoint, the cost of a careless change is paid by other people, often silently and often at the worst time. The pressure to ship a small change quickly is exactly inverse to the blast radius of getting it wrong.
The same loop, applied to this problem.
The contract is part of the plan
Shapes, status codes and error semantics are stated in the intent and fixed in the versioned plan, so a change to the contract is a visible change to a document rather than an incidental consequence of an edit.
An independent grade on every build
The reviewer evaluates the built service against the stated contract. Because it did not write the service, it has no stake in believing that the service is correct.
Gated promotion
Consumers are not exposed to a new version because a build succeeded. A person approves the deploy, with the review verdict in front of them.
Things teams actually ask for.
Written the way a request arrives, not the way a feature list describes it.
- A webhook receiver that verifies signatures and is idempotent on retry
- A REST surface over an existing database with strict pagination limits
- A scheduled sync between two third-party systems with a replay log
- A rate-limited public endpoint with explicit, documented error codes
Common questions.
- Can Fidelio work against an existing API contract?
- Yes. Provide the contract as part of the intent; it becomes part of the versioned plan and part of what the independent reviewer grades the build against.
- What stops a breaking change from shipping?
- The deploy gate. A build that changes behaviour still requires a human approval, and the review verdict is presented at the point of that decision.
Put an intent in and see what comes back.
Every run produces a plan, a build, an independent review, and a gate you control.