Compliance & Drift Analysis
The compliance service checks that what runs matches what you promised in your contract. The gap between the two is drift — like a building that no longer matches its plans.
What Stops Drift
Section titled “What Stops Drift”Why it matters. Your customers built against what you published. The day what runs stops matching it, their integration breaks — and they usually find out before you do. That should never be how you hear about it.
How. Apiway checks what runs against what you promised, at the two moments drift can happen:
- Before release, it is a gate. Every change you push is verified against its contract before it is released — including a change to your implementation that does not touch the contract. A change that does not match does not pass, so a drifting deployment is stopped before it serves anyone. It is the default: there is nothing to configure and nothing to wire into your deploy pipeline. You see the result where you already work: the pull request is marked as failing, with a comment naming what did not match the contract, and the change is not released.
- On live traffic, it is a check that never slows you down. It is on by default for every deployment — you can switch it per environment and per version. Every request and response is compared with the contract without adding latency. What it finds is reported as it happens, to your on-call through event webhooks, rather than blocking a customer’s call.
What it looks for, in both directions:
- Under-delivering — a field or status you promised is missing from what you return.
- Over-delivering — something you never declared is leaving your API. That is a contract problem and an exposure problem: data nobody agreed to share.
- Callers going off-contract — a request carrying a parameter or shape the contract does not declare.
How It Works
Section titled “How It Works”Each request and response is validated against the OAS:
- Request validation — Does the request match a documented operation? Are parameters, headers, and body correct?
- Response validation — Does the response schema match the OAS? Are status codes documented?
- Scoring — Each violation gets a severity (error, warning, info) and the API gets an overall compliance score.
What It Detects
Section titled “What It Detects”| Violation | Severity | Example |
|---|---|---|
| Undocumented endpoint | Error | GET /users/search exists but isn’t in the OAS |
| Schema mismatch | Error | Response returns userName but OAS defines username |
| Missing security | Error | Endpoint accepts unauthenticated requests |
| Wrong status code | Warning | Returns 200 for a creation that should return 201 |
| Missing headers | Warning | Response lacks Cache-Control or Content-Type |
| Type mismatch | Error | Field defined as integer, returned as string |
| Extra fields | Info | Response includes fields not in the OAS |
Compliance Score
Section titled “Compliance Score”Each API gets a compliance score based on the number and severity of violations:
- 90-100 — Clean. Minor informational findings.
- 70-89 — Needs attention. Some schema or documentation gaps.
- Below 70 — Significant drift. Design and implementation are misaligned.
The score is visible in the API catalogue, governance reviews, and the developer portal. Consumers can assess API quality before subscribing.
Design-to-Code Drift
Section titled “Design-to-Code Drift”Drift happens when your API evolves in code without updating the spec. Common causes:
- A developer adds a query parameter but doesn’t update the OAS
- A schema field is renamed in code but the spec still has the old name
- An endpoint is removed but the OAS still documents it
Apiway catches this automatically. The compliance service runs continuously — not just at deploy time, but at runtime against real traffic.
Remediation
Section titled “Remediation”When drift is detected:
- Fix the code — change the implementation to match the contract. The contract is what your customers built against; it is the part that is right by default.
- Change the contract deliberately — if the behaviour should change, that is a design decision: a new contract version, reviewed and approved like any other change, never an edit to make the spec match whatever the code happens to do.
- Governance review — significant drift triggers a governance flow so reviewers are aware
Integration with Governance
Section titled “Integration with Governance”Compliance scores feed into governance decisions:
- Reviewers see the compliance score when approving API changes
- Governance templates can require a minimum compliance score before approval
- Recurring compliance failures can trigger automated governance flows
Accessing Compliance Data
Section titled “Accessing Compliance Data”Reports are available per API, per operation, and per violation type. Results are retained for historical trending, so you can track whether your API quality is improving or degrading over time.