No install needed
The playground runs in this tab against a fake API. Hello sample, click Run, you get PASS.
User guide
HTTP tests as a text file.
SnapAPI is a small language for hitting APIs. You write a .sapi file, run snapapi, and get PASS or FAIL. A GET is enough to start. Tokens and setup can wait.
Same thing on the CLI
Quick start is that GET on your laptop, with a tiny mock server so you don’t need a public API.
The usual HTTP stuff
POST, SAVE an id, tokens, helpers — then point URL: at your own origin.
CI is the same command
Once a suite is green locally, drop snapapi in the pipeline. Reports and cassettes live under CI.
Why this exists
Most HTTP tests hide the request in helpers and fixtures. Here the file is the request.
Someone reviewing your PR should see the path, the body, and the checks without opening another file.
It reads like the API
GET: /users and EXPECT: status == 200 are the whole test. POST and SAVE are the same kind of line.
Five lines to a green run
You don’t need OpenAPI, a cassette, or a token to see PASS. Hello world is a GET against a local mock.
Just files
.sapi is plain text. It diffs and reviews like anything else in the repo.
One file for QA and backend
If both sides can read HTTP, both sides can read the suite. That’s the point.
When it fits
- Smoke and regression that should look like the real calls
- QA and backend sharing the same files
- You already curl the API and want that in git
- Running from the CLI, or from Python with
run_suites
When SnapAPI is not for you
SnapAPI isn’t designed to replace every API testing framework.
If your tests need complex programming logic, custom cryptography inside the suite, extensive Python fixtures, WebSockets, gRPC, or highly customized execution flows, keep your existing framework.
SnapAPI is for teams whose API tests mostly look like:
request → assert → extract → request → assert
If that’s 80% of your suite, SnapAPI makes that 80% easier to read, review, and maintain. The other 20% stays in Python — CALL from extensions/ for one ugly value, or pytest around the runner. The .sapi file still describes HTTP; Python does not leak into the test language. Not IF / FOR / WHILE in the file.
The longer version: When SnapAPI is not for you.
What it looks like
SUITE: Hello API
URL: mock://api
TEST: Get Users
GET: /users
EXPECT: status == 200mock://api is the playground’s fake server. On your laptop, quick start uses snapapi mock instead. Don’t try api.example.com — that host isn’t ours.
Playground vs CLI
No language server, no gRPC, no WebSockets. OpenAPI checks exist if you want them; they’re not a spec toolchain. The playground covers a useful chunk of the language. FILE, GRAPHQL, IMPORT, oauth2, schema, XPath, and CALL still need the CLI.