SANNR.

An API
client that
remembers.

Built for coding agents. What they learn about your APIs stays in your repo.

public alpha

Install it with one prompt.

Paste this into Claude Code or Codex from your repository root:

Install Sannr in this repository. From the repo root, run `npx --yes @sannr/sannr@alpha connect` and follow what it prints. It adds the Sannr skills, registers its MCP server and adds a short pointer block to AGENTS.md / CLAUDE.md. Then run `npx --yes @sannr/sannr@alpha doctor` and show me the result. doctor announces one GET to https://api.github.com/zen before sending it, so I can see the API client work (use `--offline` to skip it). Everything is stored on this machine and in this repo: no account, no Sannr server, no telemetry. If it asks for a restart, tell me; when I reopen the agent here I'll say "Finish sannr setup." What it does: https://sannr.dev/install
See exactly what it does

Questions? Ask in the Sannr Discord.

The prerequisite nobody wrote down. The call that returns 200 and quietly does nothing. The reason you chose that approach over the other one.

Sannr is an API client that remembers, built for coding agents such as Claude Code and Codex. Agents use it to call the APIs a repository owns or consumes, through its MCP (Model Context Protocol) server or its command line. What they observe and record about each API operation, such as prerequisites, quirks, response shapes and the reasons behind decisions, is kept in a .sannr folder committed with the code, with the date and where it came from. Sannr makes that knowledge available to later agent sessions and to developers who clone the repository. Sannr works alongside the Postman and Bruno collections and OpenAPI specs a team already has. It runs locally on Node.js 22 or newer, with no account, no Sannr server and no telemetry. Sannr (pronounced SAH-ner, Old Norse for “true”) is in public alpha on npm as @sannr/sannr@alpha; it is not the .NET validation library of the same name.

what's coming

Keep your tools.
Bring what you've learned.

Your team already has collections, specs and hard-won lessons built over time. Sannr is additive: it sits beside what you have and keeps what the next developer or agent needs to know.

Bring what you have

Import the Postman and Bruno collections you already use, and start from your OpenAPI specs. Each import comes with a loss report; review it before you run anything.

Lessons live with the code

What an agent learns about an API is saved as a lesson in a committed .sannr folder, with where it came from. Clone the repo, bring the knowledge.

Where your agent already works

Sannr runs where your agent works, Claude Code and Codex to start, and makes each saved lesson available to the next session. No accounts, no telemetry.

No OpenAPI spec yet? Install anyway. The API client works without one, and the map lists the routes it recognizes in your code. Sannr starts remembering an API once it has an OpenAPI file for it: the vendor's published spec, or one your agent drafts from your code or docs.

what it is

Two tools,
one folder.

The map and the client are the tools; the .sannr folder is what they remember. It holds your API knowledge, its settings and the skills, committed with your code. Setup also puts what your agent needs where it looks: the MCP registration (.mcp.json, .codex/config.toml), copies of the skills, and a short pointer block in AGENTS.md and CLAUDE.md.

A map.

Point it at a repository and it inventories the APIs it finds: the services, the routes it recognizes, who calls whom, and routes your code implements that the contract leaves out. The map is generated from your files, offline, without calling anything.

The folder.

The knowledge file, .sannr/stacks/sannr.json, records what agents observe about each operation: response shapes, the enum values a contract declares, the gotchas the documentation omits, and the decisions no traffic ever reveals, such as why an integration was rejected. It is committed with the code, so it travels with the repository.

A client.

A request client your agent calls through MCP or the command line. It sends the request, applies your credentials from environment references, returns a bounded result with the assertions you asked for, and records what it observed. The client makes the calls; the folder is what it remembers.

how it works

Import. Verify.
Deliver.

How it works, in detail

Import what you already have.

Sannr reads Postman and Bruno collections, and seeds operations from an OpenAPI contract. Every import comes with a loss report. Scripts are never executed during an import; review the report and the generated suite before you run anything.

Verify against the running service.

Read-only checks record what is actually true about each operation: the status codes seen, the field names and types, the drift between the contract and the server. Field values are never recorded unless the contract itself declares them; request and response bodies, headers and credentials never are.

Deliver it where the agent already reads.

The lessons agents record are listed, each with its operation, in the instruction files your agent loads at the start of a session, so a new session has them in view without being told to go and look.

who it's for

Teams that
ship with agents.

Sannr is for developers and teams who use coding agents to build and integrate APIs: your own services, and everyone else's. If an agent on your team has ever re-discovered the same undocumented precondition a colleague hit last month, that is the problem. Sannr is additive. Keep your API client, your collections and your specs. It sits beside them and keeps what the next developer or agent needs to know.

It works today with Claude Code and Codex, on Node 22 or newer.

teams

Rolling this out
to a team?

We're working closely with a few teams during the alpha. Tell us what you're building and we'll get in touch.

We'll use this to get in touch and to send Sannr updates.

what stays put

No accounts. No telemetry.
Nothing phones home.

Sannr has no account to create and sends nothing to us. Credentials are referenced by environment variable name; the configuration stores the name, never the value. Recorded knowledge holds field names and types, and only the values a contract declares. Request evidence stays in a local folder that Sannr's own .gitignore keeps out of the repository. The API knowledge, its settings and the skills in the .sannr folder are what's meant to be shared, and they are designed to be safe to commit.

terms

The words
we use.

API context Everything an agent needs to use an API correctly that the specification does not say: prerequisites, quirks, rate limits, the reason a decision was made, and how recently each fact was checked.
Tribal knowledge The working knowledge of a system that lives in the heads of the people who have been around longest and is not written anywhere a newcomer, or an agent, would find it.
The rediscovery tax The cost of an agent re-deriving, in a fresh session, something a previous session already learned about the same API.
Authored lesson A short note recorded on an operation by a developer or an agent, with its evidence, describing behavior the contract does not say. Sannr delivers lessons to later sessions.
Loss report The part of an import that names what could not be carried over faithfully.
Drift A difference between what the contract or the saved knowledge says and what the running service does now.
Repository-level context Knowledge committed with the code, so it travels with the repository: anyone who clones it gets the same notes. Your agent's host may keep memory for you on your machine; the repository is what everyone else pulls.

on the record

What's true
today.

Sannr is Old Norse for “true,” so we stick to what we can show. Here is what the public alpha does today.

It keeps what your agents learn. Once Sannr has an OpenAPI file for an API, it saves what your agents record about that API in your repo, with the date, the operation it belongs to and where it came from, and makes it available to the next session.

It brings in your collections. A Postman or Bruno collection becomes a runnable suite with a loss report. Review both before you run anything.

It sends nothing to us. No account, no Sannr server, no telemetry.

When we publish a number, we'll publish the experiment behind it.

tune in

Catch the
next drop.

known signal

What is Sannr?
An API client that remembers, built for coding agents such as Claude Code and Codex. What your agents learn about an API is kept beside the code, with the date, the operation it belongs to and where it came from, and made available to the next session. Public alpha on npm as @sannr/sannr@alpha. No pricing yet.
How do I install it?
Paste the prompt at the top of this page into Claude Code or Codex from your repository root. What each part does, step by step: sannr.dev/docs
Is this the .NET validation library called Sannr?
No. That is an unrelated open-source project. This Sannr is sannr.dev, an API client that remembers, for teams using coding agents to build and integrate APIs.
Do I have to drop my API client?
No. Keep the collections and tools you already use. Sannr imports them and sits beside them.
Which agents does it work with?
Claude Code and Codex, through an MCP server and a command line. It needs Node 22 or newer on macOS or Linux; native Windows isn't supported yet.
What does it import?
Postman and Bruno collections, as runnable suites with a loss report to review before you run them, and OpenAPI contracts.
Do I need an OpenAPI spec?
Not to install it or make calls. Sannr starts remembering an API once it has an OpenAPI file for it: the vendor's published spec, or one your agent drafts from your code or docs. The map lists the routes it recognizes in your code, a starting point for that draft.
Does it send anything to you?
No. Everything is stored on your machine and in your repo: no account, no Sannr server, no telemetry. Credentials are referenced by environment variable name and never stored. The team form on this page is the only thing here that talks to us.
What gets committed to my repository?
The .sannr folder: the knowledge file, configuration that names environments and credential variables, and the skills your agent uses. Setup also registers the MCP server in your agent's config (.mcp.json, .codex/config.toml), copies the skills to where each agent reads them, and adds a short pointer block to AGENTS.md and CLAUDE.md. Local request evidence is ignored by Git.
How is this different from writing a markdown file?
A well-kept markdown file works. Sannr is the thing that produces and maintains that file from what your agents observe and record, with the date, the operation it belongs to and where each note came from. We have not yet measured Sannr against a hand-kept file, and we say so.
How do you pronounce it?
SAH-ner. Old Norse sannr, meaning “true.”

who

Built by a developer
who kept walking over to Joe.

Sannr is built by Sterling Chin in the San Francisco Bay Area. He writes about APIs, coding agents and the knowledge that never makes it into the docs on LinkedIn and X.