What Tinspec is

Tinspec is a request-testing tool for backend developers. It does what Swagger UI or Scalar do — let you read and explore an API — and what Postman or Bruno do — actually send requests, save them, and chain them together — in one local application.

The two bets

Most request tools start from a blank request and expect you to fill it in. Tinspec starts somewhere else.

Descriptions are live sources, not imports. Point Tinspec at an OpenAPI document — usually one your framework already generates — and the endpoints materialise immediately, grouped by tag, with typed parameters and body fields. An OpenAPI document is one of four sources; a gRPC server with reflection on, a GraphQL endpoint’s introspection, and an MCP server’s tool list describe themselves the same way. All four are polled, not imported: when the API changes, the endpoints change with it, and you get told what moved. You are testing the current API, not a snapshot somebody imported last quarter.

Auth that fetches its own tokens. You should never paste a JWT into a header again. You describe once how a credential is obtained — a login script, generic OAuth 2.0 / OIDC, AWS SigV4, or a first-class Keycloak / Clerk / Auth0 / Firebase / Supabase integration — and Tinspec fetches it, caches it until it expires, and injects it into every request and chain that references the provider. When a token turns out to have expired early, a real 401 drops the cached one and says how long it actually lived, rather than leaving you to guess.

What it sends

HTTP, gRPC (unary and all three streaming modes), GraphQL over HTTP, WebSocket, and MCP tool calls, plus server-sent events and LangGraph agent runs. They are implementations of one common request abstraction, so they share the same engine: the same auth injection, the same {{variable}} resolution, the same cookie jar, the same history.

Why it is native

The engine is a Rust library running in-process inside the app — not a sidecar, not a server. That is the reason Tinspec is a desktop application rather than a website:

• a browser tab cannot reach localhost, and most APIs under test are on localhost;
• a browser cannot speak native gRPC;
• a browser is blocked by CORS on exactly the calls you want to make.

Sending from a local native process makes all three simply work.

What it stores, and where

Your project folder is the source of truth, and everything in it is plain YAML meant to be committed next to the API it tests. A per-project SQLite database holds run history and the spec cache and nothing else — delete it and you lose history, nothing more. Secrets never touch either: they live in your OS keychain or a machine-local encrypted store.

See Project layout for the exact file tree.

There is also a CLI

tinspec is a second, separately downloaded binary that runs your saved chains and requests headlessly, for CI. It is built on the same engine release the app pins, so a chain behaves the same in a pipeline as it does in the editor — with one exception worth knowing before you rely on it, which Run a suite in CI names. It is macOS-only today.

What it is not

Tinspec is not a hosted service you upload a collection to. The desktop app is free and fully usable offline with no account at all, and every request leaves from your own machine rather than through a Tinspec server. There is an optional paid cloud tier for sync and teams, and it is strictly additive — see Local & cloud, which also says where the source and the licence stand.