Projects
Organize your applications, with one or more environments per project (prod, staging, uat, etc.)
Projects
Projects are containers for your test plans. Each project represents a web application, and can have one or more environments (e.g. prod, staging, uat). Each environment owns its own URL, notification config, test cookies/headers, and proxy country, so you can run the same test plans against different deployments.
Creating a Project
- Go to Dashboard → Projects
- Click Create Project
- Fill in:
| Field | Description | Required |
|---|---|---|
| Name | Display name for the project | Yes |
| Default env URL | Base URL for the default prod env | No |
| Webhook / Slack | Notification config for the default env | No |
A new project is auto-created with a single prod environment. You can add more envs (and rename prod if you want) from the project edit page.
Environment URL
Each environment owns a base URL. When set, it's prepended to your test plan prompts:
Env URL: https://myapp.com
Test Plan: "Go to the pricing page and verify the free tier is listed"
Effective prompt: "This test run is for https://myapp.com.
Go to the pricing page and verify the free tier is listed"Setting the URL on each env (rather than hardcoding it in the test plan) lets the same plan target prod, staging, and uat without duplication. See Environments below.
Environments
Environments are the unit you target with a run. The default project create flow gives you a single prod env carrying your URL + notification config. Add more from the project edit page when you're ready to test multiple deployments.
Targeting an env from the API
Pass env as a string name in the run request:
# Run all plans in the project against staging
curl -X POST https://test-lab.ai/api/v1/run \
-H "Authorization: Bearer tl_xxxxx" \
-H "Content-Type: application/json" \
-d '{"projectId": YOUR_PROJECT_ID, "env": "staging"}'Omit env to use the project's default env (the one flagged is_default). When a label batch fans out across multiple projects and any project is missing the named env, the whole trigger 404s with the offending project IDs listed, so you can't accidentally run the wrong tests.
Notification routing
Each env has independent HTTP Webhook, Slack, and Teams configs, each with its own notify_on gate. A typical setup:
| Env | Webhook | Slack | Notify on |
|---|---|---|---|
prod | PagerDuty hook | #prod-incidents | Failed runs only |
staging | (none) | #qa-runs | All runs |
uat | JIRA hook | (none) | All runs |
See Webhooks and Slack Notifications for the full setup.
Project Organization Tips
For large applications, organize projects by feature area, then add environments inside each:
MyApp - Auth→ envs: prod, stagingMyApp - Checkout→ envs: prod, staging, uatMyApp - Dashboard→ envs: prod
API Access
Projects can be accessed via the API using projectId:
# Run all test plans for a project
curl -X POST https://test-lab.ai/api/v1/run \
-H "Authorization: Bearer tl_xxxxx" \
-H "Content-Type: application/json" \
-d '{"projectId": YOUR_PROJECT_ID}'See API Reference for more details.
Metrics
Each project tracks:
- Test Plan Count - Number of test plans in the project
- Run Count - Total test executions
- Build Count - Unique build IDs (for CI integration)