Skip to main content
AdCP includes comprehensive policy compliance features to ensure brand safety and regulatory compliance across all advertising operations. This document explains how publishers should implement and enforce policy checks throughout the media buying lifecycle.

​
Acceptance-policy discovery

Seller acceptance policy answers a narrower question than buyer governance: what business, campaign, creative, targeting, destination, and format will this seller accept? It does not give the seller authority over the buyer’s plan and does not expose the seller’s internal review workflow. A seller that supports structured discovery publishes media_buy.acceptance_policy_discovery from get_adcp_capabilities:
The HTTPS document at catalog_url conforms to acceptance-policy-catalog.json. Each local profiles[] entry declares coverage: "partial" or "complete" and contains rules with a disposition of allowed, conditional, or prohibited. Conditional rules carry typed requirements such as advertiser verification, prior authorization, disclosure, targeting restrictions, or sales-assisted setup. Every policy_ids[] value resolves through that profile’s digest- and version-pinned policy_refs[]. The profile’s own content_digest covers its RFC 8785 canonical form with that field omitted, making a profile ID/version immutable. Registry-published platform policies may include a reusable acceptance_profile; a seller adopts it through registry_profiles[], which pins both policy and profile versions and digests. For each adoption, resolve the exact policy version, RFC 8785-canonicalize the resolver’s canonical_content, and require its SHA-256 to equal both the resolver content_digest and the pinned policy_digest; null canonical content or a mismatch fails closed. Verify profile_digest separately against the embedded profile. The seller MUST NOT copy and alter a registry profile under the same identity; seller-specific restrictions use a separate local profile and compose restrictively. A profile ID may occur only once across a catalog’s local and registry lists. Registry publication alone never binds a seller. Products may add acceptance_policy_profile_ids[]. Resolve the seller defaults and every product profile referenced by the contemplated purchase. All selected profiles apply; for matching rules, prohibited wins over conditional, which wins over allowed. A missing capability, an omitted rule in a partial profile, or missing buyer facts means unknown, never allowed. complete is exhaustive only for that profile’s declared scope and version; the scope explicitly names countries, declared region aliases, or all_jurisdictions: true so omission cannot be mistaken for worldwide coverage. A rule matches the decision surface when applies_to[] contains that surface and its subject_category equals a declared subject. Omitted subject_facets, advertiser_roles, jurisdictions, or jurisdiction_groups are wildcards; when present, each dimension must intersect the corresponding buyer fact. Expand jurisdiction_groups only through the containing profile’s region_aliases; an unknown alias invalidates the profile and never matches permissively. Evaluate every matching rule independently, then choose the most restrictive disposition. Platforms with an exception to a broad prohibition represent it with non-overlapping facets or roles—for example, prohibit persuasive election facets while making government_information conditional for an election_authority. A request carrying both the exception facet and a prohibited advocacy facet remains prohibited. Buyers may send acceptance_context on discovery with registry category IDs, optional category facets, advertiser roles, industry, advertiser jurisdictions, and delivery jurisdictions. advertiser_jurisdictions says where the advertiser is established; delivery_jurisdictions says where ads will run and is the field matched by rule jurisdictions and jurisdiction_groups. For example, political_advertising is the broad category; facets distinguish candidate or party ads, election or ballot-measure ads, issue advocacy, legislation or regulation, government information, political merchandise, and incidental or news references. This avoids a single ambiguous political: true flag while allowing future registry categories and facets without changing the protocol schema. Discovery is advisory. Sellers may intentionally publish only partial rules, may apply account-specific or newly effective policies at execution time, and remain authoritative for an exact request. Buyer declarations are untrusted hints: sellers MUST classify creatives, destinations, advertiser identity, and targeting independently when those facts affect acceptance. Omitting or mislabeling a category or facet cannot bypass seller enforcement. A buyer MUST therefore handle a later structured POLICY_VIOLATION even when discovery appeared to allow the campaign. The catalog digest detects stale or substituted catalogs; it is not an acceptance guarantee. Fetch catalog_url as untrusted remote configuration: require HTTPS, apply the shared URL canonicalization and public-network fetch protections, do not follow redirects, do not send seller or buyer credentials, pin DNS through connection, and bound time and response size. Verify the digest over the exact received bytes before parsing or caching. Resolve every registry_profiles[] reference from the shared registry at the exact policy and profile versions and verify both digests; a missing or mismatched reference is unknown and cannot fall back to a same-named local profile. Profile and rule descriptions are display-only untrusted text; matching uses typed fields only, and implementations MUST NOT place that prose into a privileged instruction context. Cache by canonical URL plus digest, never by URL alone. Buyers can request acceptance_policy_profile_ids explicitly through either discovery surface’s fields projection.

​
Overview

Policy compliance in AdCP uses the brand field when advertiser-specific context is available. brand is optional for get_products unless the request includes catalog; it is required for create_media_buy. Brand context enables publishers to:
  • Filter inappropriate advertisers before showing inventory
  • Enforce category-specific restrictions
  • Maintain brand safety standards
  • Comply with regulatory requirements

​
Brand

Buyers should include brand in get_products when the advertiser is known so sellers can return context-rich recommendations and apply advertiser-specific policy checks. A catalog-bearing get_products request must include brand, and every create_media_buy request must include brand.
The brand domain resolves /.well-known/brand.json. On a single-brand domain, brand_id can be omitted. On a house or portfolio domain, use brand_id to select the intended entry. The selected entry provides:
  • Brand name and identity for verification
  • Industries for policy filtering
  • Brand assets for creative compliance
Callers can supply brand.industries as a per-request override when the canonical entry is missing or does not describe the campaign’s current industry context. When that field is absent, sellers and governance agents resolve industries from the selected brand.json entry. Combined with the brief field (which describes what’s being promoted), publishers have fuller context for policy decisions. When brand is absent from a non-catalog discovery request, a seller may apply general policy rules or limit the products it returns rather than perform advertiser-specific checks. For comprehensive guidance on briefs and brand information, see Brief Expectations.

​
Policy check implementation

Publishers must implement policy checks at two key points in the workflow:

​
1. During product discovery (get_products)

When a get_products request is received, the publisher should:
  1. Require brand when catalog is present
  2. When brand is present, validate it and resolve the selected brand entry and its industries
  3. Apply advertiser-specific policy checks when that context is available
  4. Otherwise, apply general policy rules or limit discovery
  5. Filter out unsuitable products
Example policy context resolution:
If this function returns None, apply general discovery policy or limit the returned products. Otherwise, evaluate policy against the resolved industries and any other applicable request context.

​
2. During media buy creation (create_media_buy)

When creating a media buy, the publisher must first require brand, then:
  1. Validate the brand against publisher policies
  2. Ensure consistency with the campaign brief
  3. Apply the seller’s internal review policy if needed
  4. Return appropriate errors for violations

​
Policy outcomes

AdCP does not define a separate policy-compliance status or response field. Use the task status and error model that matches the outcome.

​
Products can be returned

When policy checks pass, return the ordinary completed response. An empty products array means the search completed but no products matched.

​
More information is needed

Use input-required only when the buyer must supply information before the seller can continue. Include task_id and context_id so the buyer can continue the same task, plus the status-specific reason and optional suggestions.

​
Seller-side review continues asynchronously

Seller-internal review does not require buyer input or protocol-level approval orchestration. When a well-formed brief or refine request cannot finish within the current time budget, return submitted with a task_id; use working for subsequent progress. Those states communicate task completion only—the seller may use people, automation, or both internally. Wholesale discovery is synchronous and does not use these async states.

​
The seller declines a well-formed request

When the request is valid and understood but the seller makes a business decision not to offer products, use the typed rejected outcome. This remains a successful transport response.

​
The request violates a policy

When the request itself violates an applicable content or advertising policy and can be corrected, return a failed response with POLICY_VIOLATION. Populate errors[] and mirror the fatal error in adcp_error so clients can handle both response layers.

​
Creative Validation

All uploaded creatives should be validated against the declared brand identity:
  1. Automated Analysis: Use creative recognition to verify brand consistency
  2. Human Review: Manual verification for sensitive categories
  3. Continuous Monitoring: Ongoing checks during campaign delivery
This ensures:
  • Creative content matches the declared brand
  • No misleading or deceptive advertising
  • Brand safety for all parties

​
Common Policy Categories

Publishers typically implement restrictions for:

​
Blocked Categories

  • Illegal products or services
  • Prohibited content (varies by region)
  • Categories requiring special licensing

​
Restricted Categories (Conditional Acceptance)

  • Alcohol (may require age-gating)
  • Gambling/Gaming
  • Cryptocurrency/Financial services
  • Political advertising
  • Healthcare/Pharmaceuticals
  • Dating services

​
Special Requirements

  • Political ads may require disclosure
  • Healthcare may need disclaimers
  • Financial services need compliance review

​
Implementation Best Practices

  1. Clear Communication: Provide specific reasons for restrictions
  2. Contact Information: Include sales contact for restricted categories
  3. Consistent Enforcement: Apply policies uniformly across all advertisers
  4. Documentation: Maintain clear policy documentation for advertisers
  5. Appeals Process: Allow advertisers to request policy exceptions

​
Internal review and buyer interaction

Keep the two human-in-the-loop paths distinct:
  • Buyer clarification: Return input-required only when the buyer must answer a question. Include task_id and context_id, then continue that task context after the buyer responds.
  • Seller-internal review: Keep the review mechanism private. For brief or refine, return submitted when the task cannot finish within the current time budget and working while it remains active. Do not use input-required merely because a seller-side process is involved.
After review, return the canonical completed, rejected, or failed outcome.