AI API testing

API testing lets you build and send HTTP requests against your endpoints — the everyday "send a request, read the response" workflow — without leaving your project. This guide covers organizing requests and running them. It is a metered add-on, so it must be enabled for your workspace first.

What it is#

API testing gives you a Postman-style workspace inside a project at Projects → API. You organize work into collections (top-level groups), folders (sub-groups inside a collection), and requests (the individual calls you send). A request carries everything an HTTP call needs:

• Method — GET, POST, PUT, DELETE, or PATCH.
• URL and base URL — the path plus the base it's joined to.
• Headers — name/value pairs sent with the request.
• Query params — values appended to the URL.
• Body — JSON, form-data, or raw text (for the methods that send one).
• Auth — inherited from the project, or overridden per request with Basic, Bearer, or API-key credentials.

When you send a request, BugBrain shows the response status code, the response time, and the response body, saves the response, and keeps a run history so you can see how an endpoint behaved across runs.

Why use it#

• One home for testing — your API checks sit next to your UI test runs, cases, and issues, in the same project.
• No tool-switching — build, send, and inspect requests in the browser; auth is reused from the project so you're not re-entering credentials.
• AI-assisted assertions — instead of hand-writing every check, BugBrain can suggest assertions about a response (for example, that a field exists or a status is what you expect).

Before you start#

API testing is a metered, feature-flag-gated add-on. Before the page works for your workspace:

• A super-admin must turn on the api-testing feature flag for your workspace. If it's off, the page shows a "not enabled" notice with an upgrade or contact path instead of the workspace.
• You need the right permissions: api-testing:view to see requests, api-testing:create / api-testing:edit / api-testing:delete to manage collections, folders, and requests, and api-testing:execute to send a request.

Organize your requests#

1. 1

   Open API testing

   Go to Projects → API for your project.
2. 2

   Create a collection

   Add a top-level collection to group related endpoints (for example, one collection per service).
3. 3

   Add folders and requests

   Inside a collection, create folders to sub-group requests, then add requests for the individual endpoints you want to test.

Build a request#

1. 1

   Set the method and URL

   Pick the HTTP method (GET, POST, PUT, DELETE, PATCH) and enter the URL, joined to its base URL.
2. 2

   Add headers, params, and a body

   Fill in any headers and query params. For methods that send data, add a body as JSON, form-data, or raw text.
3. 3

   Choose how it authenticates

   Leave auth set to inherit from the project, or override it for this request with Basic, Bearer, or API-key credentials.

Run a request and read the response#

1. 1

   Send the request

   Run the request to call the endpoint.
2. 2

   Read the result

   See the status code, response time, and response body. The response is saved with the run.
3. 3

   Add AI-assisted assertions

   Let BugBrain suggest assertions about the response — checks you can keep so future runs verify the same expectations.
4. 4

   Compare over time

   Open the request's run history to see how its status, timing, and body have changed across runs.

Tips#

• Mirror your service boundaries with collections, and use folders for areas within a service, so a large API stays navigable.
• Keep base URLs on the request so you can point a whole collection at staging or production by changing one value.
• Use the run history to spot regressions — a status code or response time that drifts between runs is an early warning.

Related#