Introduction
Outqube tests your web app in a real browser and records proof of every step. Start runs from CI, get notified when they finish and connect your coding agent.
Outqube is an AI agent that tests your web app in a real browser, the way a QA tester does. It records every step with screenshots, console messages and network entries, and it turns a failure into a bug report with the steps to reproduce.
These docs are for the ways to use Outqube from outside the app: your pipeline, your pull requests, your chat and your coding agent. You write your tests and manage your apps in the dashboard.
Five ways in
| Surface | Use it to | Start here |
|---|---|---|
| REST API | Start runs, read results and failure reports, and manage webhooks from any language. | API reference |
| Event webhooks | Get a signed HTTPS request when a run starts, needs attention or finishes. | Webhooks |
| CLI | Run a suite from a terminal or a CI job and fail the build when a test fails. | CLI reference |
| MCP server | Let a coding agent start runs and read failure reports, so it can fix the bug itself. | MCP server |
| GitHub App | Get an Outqube check and one comment on every pull request. | GitHub App |
All of them use the same data and the same API keys, where a key is needed. A run started from the CLI shows up on the pull request check, and a run started from a pull request fires your webhooks.
Which one to pick
- Your CI runs the tests: use the CLI. It waits for the run, prints the failure reports and sets the exit code.
- Your own service starts runs or reads results: use the REST API.
- You want a result on every pull request without touching CI: install the GitHub App.
- You want to know when a run finishes: add an event webhook.
- You want an agent to debug failures: connect the MCP server.
Next steps
- Quickstart: start your first run in a few minutes.
- Authentication: create an API key and pick its scope.
- Core concepts: runs, tests, suites, environments and results.