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	HTTP Basic on every request, no token exchange. Issuer-minted tokens are never valid on the Core API.
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.

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
• 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