Cookie & Header Authentication
Configure cookies and HTTP headers for testing authenticated areas of your application
Cookie & Header Authentication
Test-Lab can inject cookies and HTTP headers before running tests, allowing you to test authenticated areas without the AI agent needing to log in manually.
Use Cases
- Session cookies - Test logged-in user flows
- Auth tokens - Access protected API endpoints
- Feature flags - Test specific feature variations
- Bypass tokens - Skip CAPTCHA or rate limiting during tests
Cookie Hierarchy
Cookies can be configured at three levels, with later levels overriding earlier ones:
Project cookies → Test Plan cookies → Runtime cookies (API)| Level | Scope | When to Use |
|---|---|---|
| Project | All test plans in the project | Shared auth across all tests |
| Test Plan | Single test plan | Test-specific auth or overrides |
| Runtime | Single test run | CI/CD dynamic tokens |
When the same cookie name+domain exists at multiple levels, the more specific level wins. Runtime cookies override test plan cookies, which override project cookies.
Privacy note: Cookies are injected directly into the browser but are never sent to or read by the AI model. Your authentication tokens remain private.
Cookie Configuration
Required Fields
| Field | Description | Example |
|---|---|---|
name | Cookie name | session_id |
value | Cookie value | abc123xyz |
domain | Domain scope | .example.com |
Domain Patterns
The domain field determines which URLs receive the cookie:
| Pattern | Matches | Use Case |
|---|---|---|
.example.com | example.com, www.example.com, app.example.com | Recommended - covers all subdomains |
example.com | Only example.com (no subdomains) | Exact domain only |
.app.example.com | app.example.com and its subdomains | Specific subdomain scope |
Always use the leading dot (.example.com) unless you specifically need to restrict to an exact domain. Without the dot, cookies won't be sent to subdomains like www. or app..
Examples
Wildcard domain (recommended):
{
"name": "auth_token",
"value": "eyJhbGciOiJIUzI1NiIs...",
"domain": ".myapp.com"
}This cookie will be sent to myapp.com, www.myapp.com, api.myapp.com, etc.
Specific subdomain:
{
"name": "admin_session",
"value": "admin_xyz789",
"domain": ".admin.myapp.com"
}This cookie will only be sent to admin.myapp.com and its subdomains.
Configuring in the Dashboard
Project-Level Cookies
- Go to Projects in the admin dashboard
- Click Edit on your project
- Expand Advanced Settings
- Add cookies under the Cookies section
- Click Save
All test plans in this project will inherit these cookies.
Test Plan-Level Cookies
- Go to Test Plans in the admin dashboard
- Click Edit on your test plan
- Expand Advanced Settings
- Add cookies (these override project cookies with the same name)
- Click Save
Test plans show a badge indicating how many cookies are inherited from the project level.
Configuring via API
Pass cookies at runtime when triggering tests:
curl -X POST https://test-lab.ai/api/v1/run \
-H "Authorization: Bearer tl_xxxxx" \
-H "Content-Type: application/json" \
-d '{
"testPlanId": 123,
"cookies": [
{
"name": "session",
"value": "dynamic_token_from_ci",
"domain": ".myapp.com"
}
]
}'Runtime cookies override any cookies configured in the dashboard.
CI/CD Integration
Generate fresh auth tokens in your CI pipeline and pass them to Test-Lab:
GitHub Actions Example
- name: Get auth token
id: auth
run: |
TOKEN=$(curl -X POST https://myapp.com/api/login \
-d '{"email":"test@example.com","password":"${{ secrets.TEST_PASSWORD }}"}' \
| jq -r '.token')
echo "token=$TOKEN" >> $GITHUB_OUTPUT
- name: Run Test-Lab tests
run: |
curl -X POST https://test-lab.ai/api/v1/run \
-H "Authorization: Bearer ${{ secrets.TESTLAB_API_KEY }}" \
-H "Content-Type: application/json" \
-d '{
"testPlanId": 123,
"buildId": "${{ github.sha }}",
"cookies": [
{
"name": "auth_token",
"value": "${{ steps.auth.outputs.token }}",
"domain": ".myapp.com"
}
]
}'Troubleshooting
Cookies not working?
- Check the domain - Use
.example.com(with leading dot) for subdomains - Verify the cookie name - Must match exactly what your app expects
- Check for typos in value - Copy-paste to avoid errors
- Test manually first - Verify the cookie works in your browser's DevTools
Test still shows login page?
- Your app may require additional cookies (e.g., CSRF tokens)
- The cookie may have expired server-side
- Check if your app validates other headers or conditions
Header Authentication
HTTP headers are useful for API authentication or when your app expects tokens in request headers rather than cookies.
Use Cases
- Bearer tokens -
Authorization: Bearer <token> - API keys -
X-API-Key: <key> - Custom auth headers - Any header your app expects
Header Configuration
Headers are simple name-value pairs:
| Field | Description | Example |
|---|---|---|
name | Header name | Authorization |
value | Header value | Bearer eyJhbGciOiJIUzI1NiIs... |
Privacy note: Headers are injected into browser requests but are never sent to or read by the AI model. Your tokens remain private.
Header Hierarchy
Like cookies, headers can be configured at three levels:
Project headers → Test Plan headers → Runtime headers (API)More specific levels override less specific ones.
Configuring in the Dashboard
Project-Level Headers
- Go to Projects in the admin dashboard
- Click Edit on your project
- Expand Advanced Settings
- Add headers under the HTTP Headers section
- Click Save
Test Plan-Level Headers
- Go to Test Plans in the admin dashboard
- Click Edit on your test plan
- Expand Advanced Settings
- Add headers (these override project headers with the same name)
- Click Save
Configuring via API
Pass headers at runtime when triggering tests:
curl -X POST https://test-lab.ai/api/v1/run \
-H "Authorization: Bearer tl_xxxxx" \
-H "Content-Type: application/json" \
-d '{
"testPlanId": 123,
"headers": [
{
"name": "Authorization",
"value": "Bearer dynamic_token_from_ci"
}
]
}'Using Credentials in Headers
Reference stored credentials to avoid hardcoding sensitive values:
{
"name": "Authorization",
"value": "Bearer {{credentials.api_token}}"
}See Credentials for more on secure value injection.
Common Header Patterns
Bearer token:
{
"name": "Authorization",
"value": "Bearer {{credentials.auth_token}}"
}API key:
{
"name": "X-API-Key",
"value": "{{credentials.api_key}}"
}Basic auth:
{
"name": "Authorization",
"value": "Basic {{credentials.basic_auth}}"
}