Account tokens and REST

Create a jt_ token in Account settings → API / MCP, then send it as Authorization: Bearer to a route in the supported routes below. Each route corresponds to an MCP tool. The same scopes, selected products and current roles apply. All other REST operations reject an account token, even if a browser session accompanies it. Existing jk_ Website API behavior is unchanged.

Read analytics

Set JELTO_TOKEN privately, then replace the host, product and date range:

curl --fail-with-body --get 'https://YOUR_JELTO_HOST/api/v1/stats' \
  -H "Authorization: Bearer $JELTO_TOKEN" \
  --data-urlencode 'product=prd_acmedemo01' \
  --data-urlencode 'metric=visitors' \
  --data-urlencode 'from=2026-09-01' --data-urlencode 'to=2026-09-07'

Discover metrics and their supported dimensions/filters at /api/v1/stats/catalog?product=YOUR_PRODUCT_ID. Dates use the product timezone unless tz is specified. REST responses retain their usual envelopes, units, retention and suppression states.

Preview and confirm a write

For jt_ requests, omitting the confirmation headers returns a preview without making a change. For example, a token with settings:write may preview a rename:

curl --fail-with-body -X PATCH \
  'https://YOUR_JELTO_HOST/api/v1/products/prd_acmedemo01' \
  -H "Authorization: Bearer $JELTO_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"name":"My product"}'

After approving the preview, repeat the identical request with these headers:

Jelto-Confirm: true
Idempotency-Key: rename-product-20260909-001

Generate a unique key for each intended change. Identical retries share the recorded result for 24 hours. Reusing a key with different arguments returns 409 idempotency_conflict. 409 outcome_unknown means the result cannot be confirmed: inspect the affected resource before deciding on another action. Do not automatically replace the key and retry, because the change may already have happened. Quota, revision and other current-state checks run when executing.

Completed retry records expire after 24 hours; an old key no longer guarantees protection from a duplicate write. Unresolved outcomes remain blocked for their key and require investigation. See MCP write troubleshooting.

Credentials are returned only on the initial successful creation. A matching retry includes metadata and secret_returned_once, without the secret. If that value was lost, revoke the credential and create a replacement.

Delegate credentials

tokens:write can create tokens with no more scope or product access than the caller. tokens:read lists the caller and its descendants. A token cannot inspect or revoke an unrelated sibling or broader ancestor. Delegation is limited to eight levels. Product-key creation also requires every requested analytics/funnel scope on the account token; it cannot issue payment or crawler intake keys.

Changing a parent's permissions, replacing it or revoking it disables its delegated credentials. All accessible products includes future accessible products and is required for products:write. OAuth always uses explicit product selection and cannot administer credentials.

Token editing and replacement, OAuth connection management, billing changes, provider connections, deletion and raw exports use the dashboard. Token create/list/revoke are the only token-management actions exposed through machine access.

Supported REST routes

Only these methods and paths accept account tokens. The tool reference lists their required scopes and role restrictions. For stats, crawler reports, the catalog and integration status, pass product as a query parameter; other product routes include it in the path.

Scroll horizontally to see more columns on smaller screens.