OAuth2 Machine-to-Machine Authentication
Connect third-party automation tools to AlterLab using the OAuth2 Authorization Code flow. Designed for server-to-server integrations where a tool needs to act on behalf of a user without storing their password.
Prerequisites
OAuth2 vs API Keys
AlterLab supports two ways for third-party tools to authenticate: direct API keys and OAuth2. Choose based on your use case.
| Aspect | Direct API Key | OAuth2 |
|---|---|---|
| Setup | Copy from dashboard, paste into tool | One-time browser flow — no copy/paste |
| Credential exposure | Key is visible in tool settings | Key is issued only to the server, never shown in the browser |
| Key rotation | Manual | Automatic on each re-authorization |
| Best for | Scripts, CI/CD, personal automation | Integrations installed by end users (n8n, Zapier, custom apps) |
Access Token = API Key
access_token returned by the OAuth2 token endpoint is a real AlterLab API key (sk_live_*). It works identically to a manually created key and can be used with the X-API-Key header on all scraping endpoints.How It Works
AlterLab implements the standard OAuth2 Authorization Code flow in two steps.
Web app requests an authorization code
The AlterLab web app calls POST /api/v1/oauth/authorize with the authenticated user's session JWT. AlterLab generates a short-lived (5-minute) authorization code and stores it in Redis.
Web app redirects to the third-party callback
The web app appends ?code=...&state=... to the third-party's redirect_uri and navigates the user there. The third-party receives the code in its callback handler.
Third-party exchanges code for an API key
The third-party's backend calls POST /api/v1/oauth/token with the code plus its client_id and client_secret. AlterLab validates the code, issues a new API key, and returns it as the access_token. The code is consumed atomically — it cannot be replayed.
Third-party uses the API key
The returned access_token is a permanent API key. The third-party stores it and uses it with the X-API-Key header on all subsequent scraping requests.
Quick Start
The following examples show the raw API calls. In practice, n8n and Zapier handle steps 1–3 automatically through their credential setup wizard.
Step 1: Get an Authorization Code
The web app calls this endpoint with the user's NextAuth session JWT in the Authorization header. No third-party credentials are needed here.
/api/v1/oauth/authorizecurl -X POST https://api.alterlab.io/api/v1/oauth/authorize \
-H "Authorization: Bearer YOUR_NEXTAUTH_JWT" \
-H "Content-Type: application/json" \
-d '{
"client_id": "n8n",
"redirect_uri": "https://your-n8n.example.com/oauth/callback",
"state": "random-csrf-token-1234",
"scope": "scrape",
"source": "n8n"
}'Response:
{
"code": "abc123xyz789...",
"state": "random-csrf-token-1234"
}| Parameter | Required | Description |
|---|---|---|
| client_id | Yes | Identifier for the third-party app (e.g. n8n) |
| redirect_uri | Yes | Where to redirect after authorization. Must be on the allowed-list (*.alterlab.io or configured redirect URIs). |
| state | Yes | CSRF protection token. Returned unchanged — verify it matches. |
| scope | No | Permission scope (default: scrape). Only scrape is currently supported. |
| source | No | Human-readable label for the integration (used in API key name). |
Step 2: Exchange for an API Key
The third-party backend calls this endpoint — no user session required. Uses client_id and client_secret for authentication.
/api/v1/oauth/tokencurl -X POST https://api.alterlab.io/api/v1/oauth/token \
-H "Content-Type: application/json" \
-d '{
"grant_type": "authorization_code",
"code": "abc123xyz789...",
"client_id": "n8n",
"client_secret": "YOUR_CLIENT_SECRET",
"redirect_uri": "https://your-n8n.example.com/oauth/callback"
}'Response:
{
"access_token": "sk_live_abc123...",
"token_type": "bearer",
"scope": "scrape"
}Codes are single-use
Step 3: Use the API Key
The access_token is a standard AlterLab API key. Use it with the X-API-Key header on any scraping endpoint.
curl -X POST https://api.alterlab.io/api/v1/scrape \
-H "X-API-Key: sk_live_abc123..." \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com"}'Token Rotation
AlterLab automatically rotates API keys on each OAuth2 token exchange. When a new token is issued for an integration that already has a key, the previous key is immediately revoked.
Automatic
No manual action needed. Re-authorizing the integration (repeating the OAuth2 flow) issues a fresh key and revokes the old one.
Prevents replay attacks
A single intercepted exchange cannot compromise a permanent key because the key changes on each authorization.
No expiry
The issued API key does not expire. It remains valid until the integration is re-authorized or the key is manually revoked in the dashboard.
Key naming
n8n Integration; other sources receive OAuth (source). You can see them in your dashboard under API Keys.Scopes
Only one scope is currently supported:
| Scope | Access |
|---|---|
| scrape | Full access to all scraping endpoints (scrape, crawl, search, map, extract). Same permissions as a manually created API key. |
Client Configuration
To register a new OAuth2 client (custom integration), contact [email protected]. You will receive a client_id and client_secret, and your redirect_uri(s) will be added to the allowlist.
Allowed redirect_uri patterns
*.alterlab.io— always allowedlocalhostand127.0.0.1— allowed in non-production environments only- Custom domains — must be explicitly added to the allowlist
Redirect URI validation
invalid_grant error.Error Reference
| Error | HTTP | Cause |
|---|---|---|
| invalid_client | 401 | client_id or client_secret is wrong |
| invalid_grant | 400 | Authorization code is invalid, expired (5-min TTL), or already used |
| unsupported_grant_type | 400 | grant_type is not authorization_code |
| invalid_grant | 400 | redirect_uri in token request does not match the one used in authorize |
| OAuth integration is not configured | 503 | Server-side OAuth credentials are missing (contact support) |