What is an API rule registry? (And why your team needs one in 2026)

What is an API rule registry?

An API rule registry is a single list of the business rules your service actually enforces, with each rule carrying the ticket that authorized it and the change that last touched it. Not endpoints. Not schemas. Rules — the kind a product manager would write in a Jira description and the kind an auditor would ask about in a SOC 2 walkthrough:

Orders must have a positive total. Refunds may not exceed the original charge. Free-tier customers are capped at 100 requests per minute. Account deletion must complete within 30 days of the request.

Most teams already enforce these rules implicitly — in validation code, in middleware, in some half-remembered branch of an if-statement. What they don't have is the registry: the place where those implicit rules become explicit, attributable, and watchable. That's the gap Stoney closes.

Why this category exists now

Three things changed at roughly the same time:

1. SOC 2 became table stakes.Mid-size B2B buyers won't sign without it. The Trust Service Criteria — especially CC7.1 (anomaly detection) and CC8.1 (change management) — assume you can produce evidence that ties production behavior back to the change that authorized it. Most engineering teams cannot.
2. AI-assisted PRs ship 5–10× faster. Code review used to be the moment a senior engineer caught a quiet rule violation. With Claude, Copilot, and Cursor in the loop, PRs are bigger, more frequent, and harder to read. The probability that a change quietly breaks an implicit business rule goes up every quarter.
3. The cost of a contract break has grown. When customers integrate against your API, a broken rule isn't a bug in yourproduct — it's a P1 in theirs. Recovery means support tickets, status page entries, and a postmortem with the customer's CTO on the call.

Together, these forces have made "the rules our API enforces" an artifact that needs to live somewhere other than tribal memory.

Why API drift detection isn't a feature of your existing tools

Plenty of products read one signal:

• Schemathesis, Spectral, OpenAPI Diff read your code or your spec. They know what the API should do.
• Datadog, New Relic, Honeycomb read your traffic. They know what the API is doing.
• Vanta, Drata, Secureframe read your compliance checklist. They know what you promised to have controls for.
• Linear, Jira read your tickets. They know what you intended to build.

Each of those is useful. None of them correlates the four. That's why a rule can be in spec, monitored by Datadog, listed in your SOC 2 controls, AND silently broken in production — and your tools won't tell you which PR did it. A rule registry is the missing layer that joins them.

What a good rule registry looks like

Five properties separate a useful registry from a wiki page that goes stale by lunch:

1. Plain-English rules, not endpoint descriptions. "Orders must have a positive total" is a rule. "POST /orders returns 201 on success" is not.
2. Each rule carries its provenance. Which ticket authorized it. Which PR last touched it. Which engineer is responsible if it breaks. No row in the registry should be an orphan.
3. The registry watches itself. Every PR is checked against the registry before merge. If a change would break or contradict a rule, the check shows up where reviewers actually look.
4. Drift gets attributed to a change, not just to a route.When a rule breaks in production, the registry should answer "which PR caused it" in one click — not a 90-minute git-blame session.
5. It produces audit evidence on demand. The registry is already the system of record for what your API enforces and how those rules changed. Exporting that as CC7.1 + CC8.1 evidence should be a button, not a quarter-long screenshotting project.

How Stoney builds the registry

Stoney installs as a GitHub App on the repositories you want analyzed. It reads three signals:

• Your code. Route definitions, handler files, and the validators they invoke — the source of truth for what is actually enforced today.
• Your pull requests. The history of how each handler became what it is. The PR titles, descriptions, and diffs that introduced or modified the rules.
• Your Jira tickets. The original authorization for each rule — the business reason a rule exists.

Stoney correlates the three and produces 20–40 rule drafts per repo with full provenance. You approve the ones that describe real business requirements; you dismiss the ones that don't. From that point on the registry is live: every PR is checked against it, every production drift gets attributed back to a change, and the registry can be exported as compliance evidence in one click. There's no SDK to install, no schema to write, and no annotations to maintain. (For more on how synthesis works, see Rule Synthesis in the docs.)

Who this is for

Three buyer profiles get the most out of a rule registry:

• Engineering leaders at growth-stage B2B SaaS. You're shipping faster than your team can mentally model, and a single PR has broken a customer contract more than once. You want a guardrail that doesn't slow merges and doesn't require your team to write tests they keep forgetting to write.
• CTOs and Heads of Security preparing for SOC 2 or ISO 27001.Your auditor is going to ask for evidence that ties production behavior to authorized changes. Generating that evidence by hand is a quarter's worth of work for someone senior.
• Platform teams at companies whose customers integrate with their API.When a customer's integration breaks, the fix is fast but the investigation isn't. A registry collapses "which change broke this?" from hours to seconds.

Getting started

The free tier covers one repository and a 7-day rolling history — enough to install the GitHub App, run synthesis on a real codebase, and see the rules Stoney pulls out before deciding whether to enforce them. Setup is under five minutes and doesn't require writing any code:

1. Install the Stoney GitHub App on the repository you want analyzed.
2. Describe your product in one sentence (this steers the rule-synthesis quality more than anything else).
3. Review the draft rules and approve the ones that describe real requirements.

From that point on Stoney runs in the background. Every PR gets a pre-merge rule check; every production drift gets a forensic report attributing it to a specific change; every rule owner gets paged in Slack when their rule breaks.

See pricing or start free. If you want to see the deeper mechanics first, read the documentation or the drift-forensics overview.