Skip to main content
get_principal returns the authenticated caller’s seller-resolved durable identity and current principal configuration with one AdCP agent: the same caller-scoped state that sync_principal replaces, plus retained superseded and revoked destination generations. A recognized durable identity remains readable before the caller has standing configuration. The read is side-effect free. It never creates a principal record, issues identifiers, sends endpoint proof challenges, mutates state, or advances configuration_version. For the full lifecycle from credentials through destination proof and readback, see Set up your buyer agent with a seller. Request schema: /schemas/3.2.1/protocol/get-principal-request.json Response schema: /schemas/3.2.1/protocol/get-principal-response.json

When to call

Call it whenever you need current state rather than a change:
  • Verify identity before configuration. A recognized result exposes the seller-resolved principal_kind and existing principal_id before the first state-changing call.
  • Bootstrap the concurrency fence. Read configuration_version before a guarded sync_principal replacement instead of writing blind.
  • Recover after local-state loss. A restarted service reads principal_id, configuration_version, every destination_ref, and each destination’s setup state before deciding what to sync.
  • Observe setup progress. After a destination returns action_required or validating, poll here until it reaches ready — or subscribe to the principal.changed webhook and use this read as the repair path. Polling never disturbs the version fence.
  • Read the negotiated async contract. The declarations state carries both the declared set and the seller-computed accepted intersection that governs webhook payload versions and signing algorithms.
  • Read reporting subscriptions (experimental, 3.3). When the seller supports the reporting_subscriptions section, each subscription returns its state (active, inactive, or action_required with issues), accepted_at for the current subscription_version (coverage starts at the first boundary at or after the latest of it, each buy’s confirmed_at, and the account’s authorized_at), prior_versions with their accepted_at while retained, the bound destination_ref, and its configuration. Deactivated subscriptions stay listed as inactive with deactivated_at while their obligations are retained. accounts_with_exceptions[] lists each account with an open coverage exception and its reasons, so a caller need not poll every account. Accounts whose authority the caller lost appear under accounts_unauthorized[] with unauthorized_at, last_owed_period_end, and withheld_period_count (and optionally the withheld obligation IDs), with no current account data, until re-grant or for status_retention_days; after that a re-grant is a fresh coverage start. Changes to either list, and a subscription moving to action_required, fire principal.changed with reason reporting_subscription_changed. Per-account coverage and exclusions for authorized accounts are read through get_reporting_status.
  • Audit generations. Superseded generations appear in each destination’s prior_destination_refs; revoked destinations appear in retired_destinations. Both remain resolvable for existing authorized account bindings and retained reporting history.
Only call this task when get_adcp_capabilities advertises adcp.principal with read_task: "get_principal". Sellers advertising principal implement both the sync and read tasks.

Identity

Identity resolution is identical to sync_principal: the seller resolves the stable authenticated principal from transport and ignores every request-body field for identity and authorization. The request body carries no parameters beyond the protocol envelope. For RFC 9421 signed callers, that stable identity is the canonical URL of the exactly matched operator brand.json agents[] entry after publication and key verification. Rotation to another key authorized for the same canonical Agent URL preserves the principal; a domain, JWKS URI, or key never replaces the Agent URL as the subject. For Web Bot Auth signed callers (experimental), the stable identity is the signer’s canonical origin, verified as Web Bot Auth identities describes. An identity-established caller (Web Bot Auth identities) gets unconfigured. Key rotation within the origin’s directory preserves the identity. principal_kind is resolved from authorization state, but the response exposes it only with a durable principal record: in current and recognized results. principal_id identifies that same record in both arms. A read never creates the record or mints the identifier; stable authentication without a materialized durable record returns unconfigured, which carries only kind and, when an application is in progress, relationship.

Results

The response reveals only the authenticated caller’s identity and state. It never exposes whether another principal exists or has configuration, and failed results carry no identity facts.

Relationship status

current, recognized, and unconfigured results MAY carry relationship (core/principal-relationship.json, experimental): the seller’s commercial relationship with the caller. It is marked x-added-in: 3.3.0; how a seller shapes a response for an older negotiated release is in versioning. relationship is omitted when the seller has no relationship with the caller and no application in progress. That is the identity-established state (Web Bot Auth identities). Because the field is returned only to the authenticated caller, it is not an onboarding oracle: it says nothing about any other agent. principal.changed fires with reason relationship_changed when status changes, and with relationship_expiring at a seller-chosen lead time before expires_at. Receivers re-read get_principal. An identity-established buyer agent whose application is under review receives:
Before configuration, a registered buyer agent with a durable principal record receives:
An authenticated caller with no durable record receives the existing result without an invented identifier or exposed party kind:
Seller-driven setup-state transitions observed through this task — a destination moving from validating to ready, a refreshed setup.expires_at — do not advance configuration_version. Only successful configuration mutations through sync_principal or sync_agent_notification_configs advance it.