API tests

Build HTTP test suites, chain requests, run them on a schedule and gate your CI.

API Tests runs HTTP checks against your services. It's included in Pro.

Suites and test cases

A suite groups requests that share a base URL and auth (none, bearer token, basic auth or an API-key header). Each test case is one request: a method, a path (relative to the base URL), headers, a body, and assertions.

Assertions

TypeExamples
Statusis 200; is one of 200, 201; between 200 and 299
JSON path$.user.id exists; $.total > 0; $.items has length 3; $.email matches /@acme\.com$/; $.tags contains "new"; $.price is a number
Headercontent-type contains json; x-request-id exists
Bodycontains, doesn't contain, or matches a pattern
Response timeunder 500 ms
JSON Schemathe response matches a JSON Schema

Every assertion is checked and reported, so a failure shows all the problems, not just the first. A case with no assertions passes on any 2xx status.

Variables, environments and secrets

Use {{name}} anywhere in a URL, header or body. Values come from, in order:

  1. Captured values from earlier cases in the same run. Add a capture such as token ← $.data.token on a login request, then use {{token}} in later requests. sqale runs a case only after the case that captures its value.
  2. The selected environment, for example Staging or Production. An environment can override the base URL with a BASE_URL variable.
  3. Workspace or project secrets.

Secrets are only sent to hosts you trust: the suite's base URL, the environment's BASE_URL, and any extra hosts you add under Suite settings → Allowed hosts. A request that would send a secret anywhere else is blocked. Secret values are never shown in run results; they appear as •••.

Running

Click Run to start a run in the background. You'll see live progress, and you can cancel it. Up to 5 cases run in parallel. Each run keeps a full record: the per-assertion results, the request that was sent (with secrets hidden) and the response.

The Overview tab shows the suite's health: the pass-rate trend, average and p95 response time per case, flaky cases, and each case's last failure.

Import

Import creates test cases from:

  • OpenAPI 3 / Swagger 2: from a URL or a file (JSON or YAML)
  • Postman collection (v2.x)
  • Insomnia export (v4)
  • cURL commands: paste one or several

You preview the requests and choose which to import. sqale can also apply the detected base URL and auth to the suite, and create an environment from the collection's variables. Credentials found in requests are moved into the suite's encrypted auth, not stored in plain text. Re-importing updates existing cases (matched by method and path) instead of duplicating them.

Schedules and alerts

Run a suite every 15 minutes, hourly, daily or weekly, against an environment of your choice. Get Slack and/or email alerts on failure, and again when it recovers. You can also choose to be alerted after every run.

Run from CI

Gate your deployments on API tests. Create a project API key (Project settings → API keys), then:

curl -fsS -X POST "https://sqalehq.ai/api/v1/suites/$SUITE_ID/run?wait=true&format=junit" \
  -H "Authorization: Bearer $SQALE_API_KEY" \
  -o api-tests.xml

The response status tells your pipeline what happened: 200 passed, 422 failed (so curl -f fails the step), 202 still running (poll /api/v1/api-test-runs/{runId}). format=junit returns a JUnit report that most CI systems can display. Without it, you get a JSON summary.

Testing a local or internal API

sqale runs your tests from the cloud, so it can't reach localhost or private network addresses (they're blocked for security). To test an API that isn't public:

  • Use a tunnel. Expose your local server with a tool like ngrok http 3000 or Cloudflare Tunnel, and use the public URL as the suite's base URL, or as an environment's BASE_URL.
  • Test a deployed environment from CI. Deploy to staging or a preview environment, then run the suite with the CI command above.