Skip to Content
Getting Started

Getting Started

Stoney is the API rule registry for engineering teams. It reads your code, your pull requests, and your Jira tickets — together — and produces the canonical list of business rules your API enforces today. When one of those rules is about to break, Stoney tells the right person before merge. When one breaks in production, Stoney points at the change that did it.

There is no code to write. No SDK to install. No annotations to maintain. You install one GitHub App, describe your product in a sentence, and approve the rules Stoney pulls out of your codebase. Five minutes from install to first rule check.

What Stoney is for

Three problems show up in every engineering organization past about ten people:

  1. Nobody knows what the API actually does anymore. Decisions made in a PR thread two years ago are now load-bearing behavior. The rules live in three places at once — in code, in Jira, in someone’s head — and nothing reconciles them.
  2. PRs ship faster than humans can read. AI-assisted coding has compressed the “PR review” loop. The probability that a change quietly breaks an implicit business rule goes up every quarter.
  3. Auditors ask for evidence the team doesn’t have. SOC 2’s CC7.1 (anomaly detection) and CC8.1 (change management) assume you can tie production behavior to the change that authorized it. Most teams can’t.

Stoney solves all three by maintaining a live registry of the rules your API enforces, with each rule connected to the ticket that authorized it and the PR that last touched it.

How the three signals come together

┌─────────┐    ┌─────────┐    ┌──────────┐
│  Code   │    │  Pull   │    │  Tickets │
│         │    │ requests│    │  (Jira)  │
└────┬────┘    └────┬────┘    └────┬─────┘
     │              │              │
     └──────────────┼──────────────┘
                    ▼
              ┌──────────┐
              │  Stoney  │   correlates them into
              └────┬─────┘   a rule registry with provenance
                   │
       ┌───────────┼───────────┬───────────┐
       ▼           ▼           ▼           ▼
  Drift        Pre-merge   Ownership    SOC 2
  forensics    PR check    + escalation evidence

Tools you already use read one signal each. Schemathesis reads your code. Datadog reads your traffic. Vanta reads your compliance checklist. Linear reads your tickets. Only Stoney reads code + PRs + tickets together — which is what makes everything downstream possible.

For a longer look at the category, see What is an API rule registry? on the blog.

What setup looks like (under five minutes, no code)

1. Install the StoneyBot GitHub App

In the dashboard, click Install StoneyBot. You choose which repositories Stoney can read. Stoney requests read-only access to repository contents, pull requests, and checks — no write access to your source.

2. Describe your product in one plain-English sentence

When the wizard asks “what does your API do?”, give it the same answer you’d give a new hire on day one:

A logistics platform for freight brokers to post loads, match carriers, and track shipments.

That single sentence steers the rule-synthesis quality more than any other input. It’s the difference between rules phrased as “Orders must have positive totals” and rules phrased as “POST /api/orders returns 200.”

3. Review your 20–40 draft rules

Stoney synthesizes the business rules your API enforces today and presents them as drafts. Each draft carries:

  • The plain-English rule statement
  • The Jira ticket that authorized it (when one exists)
  • The PR that last touched its handler
  • The owner — auto-assigned from recent git history

You approve the ones that describe real business requirements. You dismiss the ones that don’t. The whole review usually takes a product or engineering lead about ten minutes.

4. Ship

From the moment you approve your first rule, Stoney is running in the background:

  • Every PR gets a pre-merge rule check via GitHub Checks, with inline annotations on the exact file and line a change would break a rule.
  • Every drift in production opens a forensic report that names the culprit PR, the engineer, and the ticket the change now contradicts.
  • Every owner gets DMed in Slack when a rule they own breaks, with the full forensic trail attached.
  • Compliance evidence (SOC 2 CC7.1 + CC8.1) regenerates on demand from the Compliance dashboard.

What your team’s week looks like with Stoney running

Monday morning. A PR opens. Stoney’s check posts a finding inline: “This change removes the positive-total guard. Rule SALES-412 (Order total validation) requires it.” The reviewer asks the author to either keep the guard or update the rule. The PR doesn’t become a customer-impacting incident.

Tuesday at 2am. A contract test fails on the orders endpoint. Stoney’s forensic resolver runs immediately. The owner of the affected rule wakes up to a Slack DM that already names the PR, the author, the contradicted ticket, and the offending diff. She fixes it without paging anyone else.

Wednesday during onboarding. A new engineer reads the rule registry to learn what the platform guarantees. Each rule links to its authorizing ticket — so “why is this rule here?” gets a real answer.

Thursday before a board meeting. The CTO clicks Export evidence in the Compliance dashboard. SOC 2 CC7.1 (drift events with attribution) and CC8.1 (rule changes with PR + ticket linkage) render as a JSON or Markdown bundle ready for the auditor. No screenshotting.

Friday during a customer integration call. A partner asks “what does your API guarantee about refund eligibility?” The platform lead searches the rule registry and gives a real, sourceable answer in under a minute.

Where to go next

Last updated on
Building the rule registry