Skip to main content

​
Publisher / seller track (B1–B4)

Members only — Requires Basics credential (A1–A3). Four modules, ~105 minutes total.
This track teaches you to build and operate the supply side of AdCP. You’ll learn how sales agents represent publisher inventory, how buyer agents discover and evaluate your products, and how to expose delivery data and signals for measurement. The track culminates in a build project where you create a working sales agent. Completing this track (plus A1–A3) earns the AdCP practitioner credential.

​
Is this track for you?

AdCP gives publishers a single endpoint that AI buyer agents can use to discover your inventory, negotiate and create media buys, and pull delivery data — without a sales call, a custom API integration, or giving up your direct deal terms. One implementation; always-on access for buyers that operate autonomously. Engineers and ad tech builders should do B1–B4. Anyone else can pick the modules above and skip the rest.

​
What you’ll build toward

  • B4 is a build project: you create a working sales agent that handles real buyer queries — product discovery, media buy creation, creative specs, and delivery reporting
  • The agent is validated against AdCP storyboards, not just reviewed manually
  • Completing B1–B4 (plus A1–A3) earns the AdCP practitioner credential

​
B1: Designing your product catalog

~20 min | Prerequisite: A3 How a hosted sales agent works: product discovery, catalog integration, capability advertising. Walkthrough of designing your product catalog — including collections and installments for content-centric inventory like podcasts, CTV series, and live events — and configuring what buyers can discover about you.

​
Reading list

Product discovery

How buyer agents discover publisher inventory through get_products.

get_products task

Task reference: request schema, response schema, and examples.

Media products

How to structure products: formats, pricing, targeting, and availability.

Collections and installments

Model content-centric inventory: podcasts, CTV series, live events, and episodic content.

sync_catalogs task

Catalog synchronization: 13 catalog types, feed field mappings.

Capability discovery

How agents advertise their capabilities so other agents can discover what they offer.

Seller setup

How to publish seller identity, property relationships, signing keys, and publisher authorization files.

Version negotiation

Advertise your supported adcp.major_versions; reject mismatched requests with VERSION_UNSUPPORTED.

Authorized properties

How publishers declare and authorize their properties for agentic transactions.

Media buy lifecycle

The state machine sellers must honor: pending_creatives → pending_start → active → paused/completed.

​
Key concepts

  • Sales agent role — your always-on, AI-powered sales team that responds to buyer queries
  • Product catalog design — products, formats, pricing models, targeting options, availability, and shows/episodes for content-centric inventory
  • Catalog integration — sync_catalogs for product data, 13 catalog types, feed field mappings
  • Capability advertising — get_adcp_capabilities so buyers know what you support
  • Seller identity setup — publish brand.json for the organization operating the sales agent and adagents.json for publisher authorization; buyers use both to verify who operates the sales path and whether the publisher authorizes it
  • Object-presence capability principle — capabilities are declared by the presence of an object, not by booleans. If you support a feature, include the object; if you don’t, omit it. Buyers check for the object, not for "feature": true.
  • Version advertising — declare adcp.major_versions so multi-version buyers can migrate on their own schedule; validate incoming adcp_major_version and return VERSION_UNSUPPORTED when out of range
  • Lifecycle commitments — create_media_buy MAY return pending_creatives or pending_start; MUST transition pending_start → active when the flight date arrives, and notify orchestrators via webhook. Rejection is only valid from the pending states
  • Reporting declaration — every product MUST include reporting_capabilities (metrics, dimensions, cadence, measurement windows). Presence of this object declares get_media_buy_delivery support

Start B1 with Addie

“I’d like to start certification module B1.”

​
B2: Creative specifications and format support

~20 min | Prerequisite: B1 Deep dive on canonical Product.format_options[] and publisher adagents.json.formats[], including how buyers discover what your inventory accepts. Guide to structuring creative specs, handling incoming creatives, and brand compliance.

​
Reading list

Brief expectations

What buyer briefs look like and how to structure products so agents can match them.

Example briefs

Real examples of product discovery queries from buyer agents.

Canonical formats

How publisher, product, and creative-agent declarations work.

Creative formats

Format definitions, technical specs, and the renders structure.

Implementing standard formats

Standard format IDs and how to implement them consistently.

Product refinement

How buyer agents refine searches and negotiate product parameters.

​
Key concepts

  • Format declarations — Product format_options[] tells buyers what each sellable product accepts
  • Format vs manifest — the format is what you accept, the manifest is what gets delivered
  • Handling incoming creatives — sync_creatives and build_creative validation and approval
  • Brand compliance — understanding incoming brand.json, disclosure positions

Start B2 with Addie

“I’d like to start certification module B2.”

​
B3: Measurement, signals, and optimization

~35 min | Prerequisite: B2 How to expose delivery data, measurement signals, and optimization levers through your sales agent. Integration with measurement platforms, audience handling, and account management.

​
Reading list

get_media_buy_delivery task

Delivery metrics: impressions, spend, completion rates, and performance data.

Reporting Core obligation lifecycle

See exactly when obligations exist and how expected_at is derived.

get_reporting_status task

Project obligations, immutable revisions, health, and retained reporting history.

Broadcast measurement windows

Follow the declared Live/C3/C7 progression and its delivery fields.

Signals overview

The signals protocol: audience segments, contextual signals, measurement data.

Trusted Match Protocol

How publishers support impression-time execution for buyer use cases like cross-publisher frequency capping.

TMP Router architecture

Deployment, fan-out, and provider configuration for publishers.

get_signals task

Signal discovery: what measurement data is available and how to expose it.

activate_signal task

Enabling specific measurement on a campaign.

Accounts overview

The commercial layer: advertisers, operators, authentication, and billing.

Campaign governance

Seller-side governance checks: validate buyer purchases before executing them.

check_governance task

The governance validation task: intent checks, execution checks, statuses, and planned delivery.

​
Key concepts

  • Delivery reporting — accurate metrics via get_media_buy_delivery, plus durable obligations and missing-first-report detection through reporting.core and get_reporting_status
  • Signals framework — get_signals and activate_signal replace fragmented measurement vendor integrations
  • Audience handling — sync_audiences for accepting buyer audience data
  • Execution integration — publishers participate in TMP by sending Context Match requests (page content + available packages) and Identity Match requests (user token + package IDs) to the TMP Router, then joining the results locally. This enables cross-publisher frequency capping and impression-time activation without exposing user identity and page context to the buyer simultaneously. TMP is an experimental surface in AdCP 3.0 (feature id trusted_match.core); execution and privacy details may change between 3.x releases with at least 6 weeks’ notice.
  • Account management — sync_accounts, list_accounts for managing buyer relationships
  • Seller-side governance — when a buyer account has governance_agents (synced via sync_governance), call check_governance with governance_context + purchase_type + planned_delivery before confirming media buys
  • Planned delivery — describe what you will actually deliver; the governance agent validates it against the buyer’s plan

​
Exact B3 reporting references

​
Broadcast C3/C7 windows

C3 and C7 are common broadcast window IDs, not protocol-defined deadlines. The seller’s product is authoritative: read each entry in reporting_capabilities.measurement_windows[], especially window_id, duration_days, expected_availability_days, and is_guarantee_basis. duration_days describes accumulation; expected_availability_days also includes vendor processing. Do not infer availability from the string c3 or c7 alone. The exact delivery progression is documented in Measurement maturation windows. Read by_package[].measurement_window, supersedes_window, is_final, and finalized_at; a wider window uses notification_type: "window_update". The guarantee basis is the product’s declared window, not automatically C7.

​
Reporting-obligation lifecycle

The configuration generation creates the reporting clock; accepting a media buy does not. The seller commits an obligation independently of report data at period.end, before its first revision, and exposes it in the first ledger snapshot strictly after that boundary. Both sides derive:
This is the existing rule in Reporting Core: Lifecycle at a glance and get_reporting_status: Reliability model. The latter is also the field-level reference for reporting_obligation_id, the immutable configuration identity (delivery_config_id plus delivery_config_version), report_definition_id, period, expected_at, schedule, health, production_status, revision_count, and issues[]. Before expected_at, an obligation with no revision is waiting. Once due, it is delayed only while the seller’s advertised automated_recovery_window_seconds is running, then becomes action_required. A published zero-row revision is a report; production_status: "published" and revision_count distinguish it from a missing revision. get_reporting_status is authoritative; reporting notifications are optional wake-ups.

​
Exercises

Given sample Context Match and Identity Match responses, determine which packages the publisher activates and what targeting key-values to set. Broadcast delivery reporting: Given a broadcast product that declares C3 and C7 entries with explicit duration_days, expected_availability_days, and is_guarantee_basis, inspect a provisional delivery row with measurement_window: "c3" and is_final: false. Use the product’s declared timing—not the window names—to explain what is available, whether C7 is due, and how a later window_update should supersede C3 without making the provisional row look like underdelivery. Reliable reporting (10–15 minutes): Run reporting_core_lifecycle_probe against the sales sandbox. Save the complete configuration, period, obligation ID, expected_at, and recovery deadline returned by prepare; make a four-row observation table for waiting, delayed, zero-row, and missing-obligation states. Read the same obligation before its first revision, advance it beyond its SLA, and publish the explicit zero-row revision. Reset with prepare, run omit_obligation, and show that the returned expected period is absent from the complete periods result even though your saved configuration requires it. Submit the table plus a short explanation of the authoritative read and optional doorbells. Common errors Addie will flag: starting the clock at buy acceptance, treating zero rows as no report, trusting the seller’s returned obligations as the denominator, or using a notification as proof of ledger state.

Start B3 with Addie

“I’d like to start certification module B3.”

​
B4: Build project — your first sales agent

~45 min | Prerequisite: B3 Create a working sales agent that responds to real buyer queries. Point your AI coding assistant (Claude Code, Cursor, Copilot) at the build-seller-agent skill file — it generates an agent validated against AdCP storyboards, with optional comply_test_controller scaffolding for deterministic lifecycle testing in sandbox mode. The skill tested is specifying correct AdCP behavior.

​
What you’ll build

  • Product catalog with at least 3 products and sync_catalogs support, each product declaring reporting_capabilities
  • get_adcp_capabilities that declares adcp.major_versions and validates adcp_major_version on incoming requests — including a truthful capabilities.idempotency.replay_ttl_seconds declaration
  • Creative format support for at least 2 formats
  • Handles get_products, create_media_buy, sync_creatives, get_media_buy_delivery
  • Account setup via sync_accounts
  • Well-known discovery files: brand.json for the sales-agent operator’s identity, endpoint declarations, and signing-key discovery; adagents.json for publisher properties and agent authorization
  • Proper error responses for invalid requests — including VERSION_UNSUPPORTED, GOVERNANCE_DENIED, TERMS_REJECTED, IDEMPOTENCY_CONFLICT, and IDEMPOTENCY_EXPIRED where applicable
  • Idempotency enforcement on every mutating request: reject missing or malformed idempotency_key with INVALID_REQUEST before touching business logic; cache only on success; scope per authenticated agent
  • Lifecycle transitions: seller moves media buys through pending_creatives → pending_start → active and notifies via webhook on each transition

​
How you’ll validate

Run the media_buy_seller storyboard against your running agent:
The storyboard exercises the complete buyer workflow — discovery, account sync, media buy, creatives, delivery — and validates every response. See Validate Your Agent for setup and debugging.

​
Specialisms you can claim

Declare media_buy in supported_protocols and choose the specialism that matches your inventory model. Each specialism has a compliance storyboard at /compliance/{version}/specialisms/{id}/ that verifies your claim:
  • sales-guaranteed — guaranteed with human IO approval
  • sales-non-guaranteed — auction-based
  • sales-proposal-mode — deprecated in 3.1; use sales-guaranteed + media_buy.supports_proposals: true instead
  • sales-catalog-driven — catalog-driven commerce with conversion tracking
  • sales-broadcast-tv — broadcast linear TV
  • sales-dooh — non-guaranteed digital out-of-home venue and screen inventory
  • sales-social — social platform with self-service flows
See the Compliance Catalog for the full list.

​
Assessment rubric

Passing threshold: 70%. Any AI coding assistant is welcome (Claude, Cursor, Copilot, etc.). The skill tested is: “Can you specify correct AdCP behavior?”

Start B4 with Addie

“I’d like to start certification module B4.”

​
What’s next

After completing B1–B4, you’ve earned the AdCP practitioner credential. From here you can pursue specialist modules: