Personal Access Tokens

Personal Access Tokens (PATs) provide programmatic access to the LogPulse management API — the endpoints you would otherwise reach through the dashboard, such as the AI Evaluations API. A PAT is tied to your personal account and to one organization, and is limited to the scopes you select when creating it. You create and manage tokens in the dashboard under Settings → Access Tokens.

Because a PAT belongs to a person (not to the organization as a whole), every action performed with it is attributable to you in the audit log, and tokens are automatically removed when the owning account is deleted — there are no orphaned credentials after offboarding.

PATs vs. Ingest API Keys

LogPulse has two distinct credential types. They are not interchangeable: an ingest key is rejected on management endpoints, and a PAT is rejected on ingest endpoints.

	Personal Access Token	Ingest API Key
Prefix	lpat_	lp_
Bound to	A user + organization	The organization
Permissions	Scoped (resource:action)	Ingest only, no scopes
Used for	Management API (evaluations, automation)	Log ingestion (agents, OTLP, HTTP API)
Managed in	Settings → Access Tokens	Integrations → HTTP API

Note

For sending logs to LogPulse, use an ingest API key — see the HTTP API documentation. This page covers PATs for the management API only.

Token Format

Tokens start with the lpat_ prefix followed by 48 hexadecimal characters. The prefix makes PATs easy to recognize in configuration files and secret scanners, and distinguishes them from ingest keys (lp_).

Token format

lpat_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4

LogPulse stores only a SHA-256 hash of the token. The full token is shown exactly once, at creation time — it cannot be retrieved afterwards. The dashboard displays only the first 13 characters (the token prefix) so you can tell tokens apart.

Scopes

Scopes follow a resource:action convention. A token can hold any combination of scopes; endpoints require specific scopes and reject tokens that lack them with HTTP 403. A token never grants more than your own permissions in the organization — scopes can only narrow access, not widen it.

Scope	Grants	Typical use
evaluations:read	Read evaluations and run results	Reporting, dashboards over verdicts
evaluations:write	Create, update and delete evaluations	Infrastructure-as-code, sync scripts
evaluations:run	Trigger evaluation runs, including ad-hoc runs	CI pipelines, detection testing

Note

More resources (alerts, dashboards, and others) will gain scopes over time as the management API expands. Existing tokens are unaffected: a token only ever holds the scopes it was created with.

Creating a Token

In the Dashboard

Tokens are created in your LogPulse settings: navigate to Settings → Access Tokens and click Create token. Then:

1. Enter a descriptive name (for example "CI pipeline" or "Detection test runner"). The name is how you will recognize the token later, so name it after the system that will use it.

2. Select the scopes the token needs. Follow least privilege: a CI job that only triggers evaluation runs needs evaluations:run and nothing else.

3. Click Create token. The full token is displayed once — copy it now and store it in your secret manager. After you close the dialog, only the prefix remains visible.

Warning

The token is shown only once. If you lose it, revoke it and create a new one — there is no way to recover the secret.

Via the API

Token management endpoints are available under /api/v1/personal-access-tokens. These endpoints use your dashboard session for authentication (a PAT cannot create other PATs), so they are primarily useful from browser-based tooling. For most automation setups, create tokens in the dashboard.

Method	Endpoint	Description
GET	/api/v1/personal-access-tokens	List your active tokens in the current organization
POST	/api/v1/personal-access-tokens	Create a token; the response contains the secret once
DELETE	/api/v1/personal-access-tokens/:id	Revoke a token immediately

POST /api/v1/personal-access-tokens — request body

{
  "name": "CI pipeline",
  "scopes": ["evaluations:run"],
  "expiresAt": "2026-12-31T00:00:00Z"   // optional
}

Response (the secret is returned exactly once)

{
  "data": {
    "token": {
      "id": "9b2f1c4e-...",
      "name": "CI pipeline",
      "tokenPrefix": "lpat_a1b2c3d4",
      "scopes": ["evaluations:run"],
      "lastUsedAt": null,
      "expiresAt": "2026-12-31T00:00:00.000Z",
      "createdAt": "2026-06-12T09:30:00.000Z"
    },
    "secret": "lpat_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4"
  }
}

Using a Token

Send the token as a Bearer token in the Authorization header on every request to a PAT-protected endpoint:

Authenticated request

curl https://api.logpulse.io/api/v1/evaluations/run-adhoc \
  -H "Authorization: Bearer lpat_your_token_here" \
  -H "Content-Type: application/json" \
  -d '{ ... }'

Each successful use updates the token's "last used" timestamp, visible in Settings → Access Tokens. Use it to spot tokens that are no longer in use and can be revoked.

Expiration & Rotation

Tokens can optionally be given an expiration date at creation time. An expired token is rejected with HTTP 401 and code PAT_EXPIRED. Tokens without an expiration date remain valid until revoked.

To rotate a token: create a new token with the same scopes, update the consuming system to use it, then revoke the old token. Because tokens are independent of each other, this gives zero-downtime rotation.

Tip

Set an expiration date on tokens used in experiments or short-lived projects, and establish a rotation schedule (for example every 90 days) for long-lived automation tokens.

Revoking a Token

Revoke a token from Settings → Access Tokens using the delete button next to the token, or via DELETE /api/v1/personal-access-tokens/:id. Revocation takes effect immediately: any request using the revoked token receives HTTP 401 with code PAT_REVOKED. Revocation cannot be undone.

You can only revoke your own tokens. Token creation and revocation are both recorded in the organization's audit log.

Warning

Revoking a token immediately breaks every integration that uses it. Make sure consuming systems have been switched to a replacement token first.

Authentication Errors

PAT-protected endpoints return the following errors. The code field in the response body is stable and safe to match on programmatically.

HTTP status	Code	Meaning
401	UNAUTHORIZED	No Authorization header, or not a Bearer token
401	INVALID_PAT	Token is not an lpat_ token, or does not exist
401	PAT_REVOKED	Token has been revoked
401	PAT_EXPIRED	Token has passed its expiration date
403	INSUFFICIENT_SCOPE	Token is valid but missing a required scope

Example error response

{
  "error": "Insufficient token scope",
  "code": "INSUFFICIENT_SCOPE",
  "message": "This token is missing the required scope(s): evaluations:run"
}

Security Best Practices

Treat a PAT like a password: anyone holding it can act on your behalf within its scopes.

Use one token per system. Give your CI pipeline, your sync script, and your reporting job each their own token. This limits blast radius and lets you revoke one integration without breaking the others.

Grant the minimum scopes. A token that only triggers evaluation runs should hold only evaluations:run.

Store tokens in a secret manager (GitHub Actions secrets, Vault, or your platform's equivalent) and inject them as environment variables. Never commit tokens to version control.

Review your tokens periodically. The "last used" column in Settings → Access Tokens shows which tokens are still active — revoke anything you no longer recognize or need.