Documentation Index
Fetch the complete documentation index at: https://docs.adcontextprotocol.org/llms.txt
Use this file to discover all available pages before exploring further.
brand.json is not only for advertisers. On the sell side, it is the public company record for the organization operating an AdCP sales path: name, logo, domains, sales agents, and signing-key discovery. adagents.json is the publisher’s authorization record: which properties exist and which agents may sell them.
Buyer agents need both views. brand.json answers “who is this seller or platform, and what is it claiming?” adagents.json answers “does the publisher authorize this agent to sell this inventory?”
Requirement boundary
The practical rule is:- If you operate an AdCP agent, that agent needs operator identity and signing-key discovery. Publish a
brand.jsonentry for the operating organization, list the agent inagents[], and expose public keys throughagents[].jwks_urior the default/.well-known/jwks.json. - If you publish inventory, you need a publisher authorization record. Publish
adagents.jsonon the publisher domain so buyers can verify which agents may sell which properties. - If you both publish inventory and operate the sales agent, do both on the same organization/domain.
- If you delegate sales to another operator, your
adagents.jsonis the authorization hinge. Your ownbrand.jsonis still recommended for publisher identity, portfolio context, and governance, but the delegated operator’sbrand.jsoncarries the sales-agent identity buyers interact with.
Who publishes what
| Organization | Publish brand.json? | Publish adagents.json? | Why |
|---|---|---|---|
| Publisher selling direct | Yes | Yes | The publisher is both the inventory owner and the sales operator. Buyers verify its identity, sales endpoint, keys, and property authorization from the same organization. |
| Publisher delegating sales | Recommended | Yes | The publisher’s adagents.json authorizes the external sales agent. Its brand.json gives buyers the publisher’s own identity and house/portfolio context, but the external operator’s brand.json carries the sales-agent identity. |
| Network, SSP, or sales representative | Yes | Usually no, unless it also owns properties | The operator’s brand.json declares its sales agent, signing keys, and represented properties. The publisher confirms the relationship in its own adagents.json. |
brand.json lives on the operator domain and the publisher’s adagents.json lives on the publisher domain.
How verification works
The sell-side chain is bilateral:- The seller’s
brand.jsondeclares the sales agent inagents[]. - The seller’s
brand.jsondeclares the properties it owns, sells directly, manages, or represents inproperties[]. - The publisher’s
adagents.jsondeclares the same sales agent inauthorized_agents[]. - For delegated or network paths, the
relationshipvalue inbrand.jsonmatches the publisher’sdelegation_typeinadagents.json. For first-party inventory,relationship: "owned"is inline ownership and has nodelegation_typecounterpart. - The signing key used by the agent is discoverable from the seller’s
brand.jsonagents[].jwks_uri; for mutating seller authorizations, the publisher also pins allowed keys inadagents.jsonauthorized_agents[].signing_keys[].
Direct publisher example
A publisher with its own sales agent publishesbrand.json at https://streamhaus.example/.well-known/brand.json:
adagents.json at https://streamhaus.example/.well-known/adagents.json:
agents[].url in brand.json matches authorized_agents[].url in adagents.json, that StreamHaus owns the property it claims, and that signed mutating responses use a key pinned by StreamHaus in signing_keys[].
Delegated seller example
When a network sells another publisher’s inventory, the network publishes its ownbrand.json:
https://streamhaus.example/.well-known/adagents.json:
brand.json alone is not authorization. Any operator can claim a property. The publisher’s matching adagents.json entry is what turns the claim into an authorized supply path.
Setup checklist
- Publish
brand.jsonfor each organization that operates an AdCP sales agent athttps://{seller-domain}/.well-known/brand.json. - Add a
salesentry toagents[]for each AdCP sales endpoint the organization operates. - Publish the endpoint’s JWKS through
agents[].jwks_uri, or rely on the default/.well-known/jwks.jsonon the agent origin. - Add every owned, direct, delegated, or network-represented property to
properties[]with the rightrelationship; useownedfor first-party inventory. - Publish
adagents.jsonon each publisher domain that owns the inventory. - In
authorized_agents[], list the seller’s agent URL, authorization scope, matchingdelegation_typefor delegated or network paths, andsigning_keys[]for any mutating seller authorization. - Keep both files aligned when a sales relationship, endpoint, or signing key starts, changes, or ends.
Where to go next
- brand.json reference — field-level details for
agents[],properties[], and property relationships - adagents.json reference — publisher-side authorization and
delegation_type - Seller verification — buyer-side walkthrough of the full verification chain
- Seller integration guide — full AdCP sales-agent implementation path