Authority keys are per-tenant Ed25519 with statuses ACTIVE / PREVIOUS / RETIRED. Fetch the current set and select the one whose kid matches the token header.

curl "https://api.intended.so/tenants/$INTENDED_TENANT_ID/authority-keys/public"

The same keys are served as a standard JWKS at /.well-known/authority/:tenantId/jwks.json (also public, cacheable for 5 minutes).

The response is { "tenantId": "…", "keys": [ { "kid": "…", "publicKeyPem": "…", "status": "ACTIVE" }, … ] }. Decode the token header to read its kid, then pick the matching key. To inspect a token's header and claims without verifying:

intended inspect-token --token "$TOKEN"

Verify locally with the library, with the CLI, or through the hosted endpoint. All three run the same checks.

curl -X POST https://api.intended.so/verify/token \
  -H "Authorization: Bearer $INTENDED_API_KEY" \
  -H "x-tenant-id: $INTENDED_TENANT_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "token": "eyJhbGciOiJFZERTQSIsImtpZCI6Im…",
    "publicKeyPem": "-----BEGIN PUBLIC KEY-----\n…\n-----END PUBLIC KEY-----",
    "expectedKid": "tenant_acme_prod-1717800000-a1b2c3",
    "expectedTenantId": "tenant_acme_prod"
  }'

From the command line, verify returns exit code 0 when valid and exit code 2 when invalid, so it slots into CI gates:

intended verify \
  --token "$TOKEN" \
  --key ./tenant-public.pem \
  --kid tenant_acme_prod-1717800000-a1b2c3 \
  --tenant tenant_acme_prod
# exit 0 → valid, exit 2 → invalid

The hosted endpoint returns the verification verdict plus the parsed claims and header:

{
  "protocolVersion": "intended.authority.v1",
  "verificationModel": "deterministic-asymmetric-hash-chain",
  "valid": true,
  "reason": null,
  "claims": {
    "intentId": "8aa3f5f6-b1a9-4c5b-a29f-b489f7d0be58",
    "tenantId": "tenant_acme_prod",
    "adapterId": "decision-only",
    "decision": "APPROVED",
    "nonce": "f3a9…",
    "issuedAt": "2026-06-07T12:00:00.000Z",
    "expiresAt": "2026-06-07T12:05:00.000Z"
  },
  "header": { "alg": "EdDSA", "kid": "tenant_acme_prod-1717800000-a1b2c3" }
}

When valid is false, reason carries one of the codes from the table above and claims may be null.

• valid: true and the claims match what you expected — proceed with the action.
• valid: false — stop. Do not execute. Re-evaluate through POST /intent if the action still needs to happen.

A token is single-use: each carries a unique nonce. Intended never runs the action, so the service that acts on the token enforces single use: record each accepted (tenantId, nonce) pair (a unique constraint works well) and reject a token whose nonce you have already seen. Do this as part of acting, in this order: decode kid → select the public key → Ed25519-verify with kid pinning → assert tenant and target → assert decision === "APPROVED" → check expiry → consume the nonce → act.

If you verify through the hosted endpoint, Intended can record the use for you: send "consume": true (with expectedKid). The first such call for a valid token answers valid: true, consumed: true; any later one answers valid: false, consumed: false with reason TOKEN_ALREADY_CONSUMED, including concurrent calls. Without consume the hosted check is read-only and does not use the token up. Single use holds only where the acting service enforces it: with consume: true here, or with its own nonce record. A signature check alone accepts the same token for its whole lifetime. Note that an idempotent retry of POST /intent (same Idempotency-Key, within 24 hours) returns the original token again, which may already be consumed.