Your API’s callers aren’t all people. AI agents act inside your customers’ organizations, services call other services, and CI jobs provision resources — and each of them needs an identity that can be scoped, suspended, and audited individually, instead of borrowing a user account or sharing one API key. This page is the whole path: the identity model for non-human callers, choosing the right credential, a working integration, and going live.

If you’re instead building sign-in for people, start from the B2C login pillar (individual consumers) or the B2B SaaS pillar (teams with organizations and invitations).

The path

1. Understand how non-human identities are modeled → concepts
2. Choose the right credential for each caller → decision
3. Build an authenticated agent or service → quickstart & guides
4. Harden for production → go-live checklist
5. Look up exact request/response behavior → API reference

---

1. Understand the model

Two concept pages carry everything on this path — fifteen minutes total:

• Agents — first-class non-human identities (agt_): the verifier model (secret and wallet), per-agent scopes, organization membership alongside humans, fixed 5-minute tokens, and the dat attestation claim that lets your API tell agent tokens from user tokens. This is the core concept — don’t skip it.
• Clients — the OAuth applications your issuer knows about, including M2M clients that mint client_credentials tokens for service-to-service calls.

Agents can join organizations as members with the same primitives as people (“the deploy bot is in the Platform org with deploys:execute”), and every mutation lands in the event trail.

2. Choose the credential

There are three credentials for code that calls APIs without a user present, and they are not interchangeable. Pick by destination first, then by identity model:

The caller is…	Use	Why
Your backend, a CI job, or a script calling the AuthPI Core API (api.authpi.com)	An org API key	A credential for managing AuthPI resources; see the guide for its authentication contract.
One of your services calling another of your services	An M2M client with client_credentials	Your API verifies a standard short-lived JWT instead of holding shared secrets for every caller.
An actor in your product — an AI agent or bot that needs its own memberships, scopes, and audit trail	An agent identity	Individually addressable: scope, suspend, audit, or delete one agent without touching the rest.

The full three-way comparison — credential shapes, token lifetimes, rotation, and storage — lives in Machine-to-machine auth.

If a service is acting on a human’s existing grant, follow MCP token exchange for your own API. For the separate task of AuthPI account administration, see Inspect your AuthPI account with MCP.

3. Build it

Give an agent an identity (10 minutes, terminal only):

• AI agents quickstart — create an agent, add a secret verifier, mint a client_credentials token, and validate it in your API, end to end.

Then go deeper, per caller type:

• Agent identities — model your fleet: one agent per workload, verifiers, org membership, zero-downtime secret rotation, suspension
• Machine-to-machine auth — the three credentials side by side, with working token flows for each
• MCP token exchange — let your MCP backend call your API on behalf of a user under your issuer
• API keys — scoped keys for everything that manages AuthPI resources
• Validate tokens in your API — verify signature and claims; gate agent traffic on dat.type === "agent"

4. Go to production

Don’t ship until you’ve worked through these:

• Verify tokens correctly — signature, iss, aud, and expiry on every request; treat dat.type as the semantic guard for agent traffic
• JWKS & key rotation — cache keys, handle unknown kid on rotation
• Plan secret rotation — all three secret types are shown once at creation; agents rotate by adding a second verifier, keys via /rotate with a 15-minute overlap
• Webhooks — react to agent.created, agent.verifier.added, and agent.updated (which carries status changes like suspension) instead of polling
• Rate limits — agents re-mint tokens every 5 minutes by design; budget the token endpoint accordingly
• Idempotency — safe retries when provisioning agents and keys from automation

5. API reference

When you need exact parameters and response shapes:

• Agents — Core API — agents and their verifiers, all operations
• Core API reference — API keys, organizations, members, webhooks
• Token claims — every claim in an agent token, including dat
• OIDC compliance — the client_credentials grant and token endpoint behavior