Start

When SnapAPI is not for you

SnapAPI isn’t designed to replace every API testing framework. That’s on purpose.

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.

Use SnapAPI

  • The file should read as the HTTP contract
  • Smoke, regression, OpenAPI checks
  • Someone who doesn’t write Python can still review the PR

Keep the other tool

  • Loops, branches, try/catch as the test
  • WebSockets, SSE, gRPC
  • Importing 2,000 existing pytest/Karate/Postman cases

The language stays small

There is no IF, FOR, WHILE, or TRY in .sapi files. Adding those would make the file a worse Python, and you’d lose the reason to use SnapAPI.

Need more power? Leave the test language alone. CALL a Python extension and bring the result back. CALL is for computation, not for driving the system under test. .sapi describes what the API test does. Python handles the one weird value.

The suite never names a .py file. The function returns a value; it does not mutate SnapAPI state, skip steps, fire extra requests, or branch the suite.

Listeners and run_suites() wrap the run. Plugins fill a hole inside a request. Pytest stays the hatch for everything else.

The test that matters

Can someone look at a .sapi file and understand the exact HTTP contract without knowing a programming language?

If a feature makes that answer “no,” it doesn’t belong in the DSL.