Overview - QA Wolf Docs

For most use cases, @qawolf/ci-sdk is recommended over direct endpoint access.

Authentication

All endpoints require a QAWOLF_API_KEY passed as a Bearer token.

Authorization: Bearer $QAWOLF_API_KEY

Kinds of API key

Kind	Acts as	Where to create it
Workspace	One workspace	Workspace Settings → Integrations → API Access
Organization	The whole organization, across every workspace in it	Workspace Settings → API Keys
User	The member who owns the key, across every workspace they can reach	Workspace Settings → API Keys

To reach either settings page, open the Workspace Name dropdown in QA Wolf.

Which workspace a request acts on

A workspace API key implies its workspace, so requests never name one. An organization or user API key does not, so a request that is scoped to a single workspace resolves it in this order:

The workspace named by a resource in the request, such as environmentId.
The workspace named by workspaceId.
Your organization’s first-created workspace.

Creating another workspace never changes step 3, so a pipeline that relies on it keeps running. Even so, pass workspaceId when your organization has more than one workspace: it states which workspace you meant, and it keeps working if the first-created workspace is ever deleted or disabled. Copy the ID from Workspace Settings → API Keys.

Base URL

https://app.qawolf.com

Endpoints

Endpoint	Method	Description
`/api/webhooks/deploy_success`	`POST`	Notify QA Wolf of a successful deployment to trigger a run.
`/api/webhooks/environment_terminated`	`POST`	Notify QA Wolf that an ephemeral environment has been terminated.
`/api/v0/ci-greenlight/{root-run-id}`	`GET`	Poll for the outcome of a run to gate a pipeline.
`/api/v0/run-inputs-executables-signed-urls`	`GET` + `PUT`	Generate a signed URL and upload an executable file.

Last modified on August 7, 2026

⌘I