Overview
A property list is a named, advertiser-scoped collection of typed identifiers (websites, mobile apps, CTV apps) used to shape where a brand’s media runs. Lists carry apurpose of either include (only buy on these
properties) or exclude (never buy on these properties). Once created, lists
are linked to the brand’s targeting profile and enforced when you buy:
include lists travel to sales agents as ADCP targeting, and exclude lists
filter conflicting inventory out at selection time.
Property lists are a buyer-curated concept. They are owned by your
advertiser and validated against the AAO property registry. Include lists are
pushed to sales agents as a PropertyListReference that the agent resolves on
demand; exclude lists are enforced by Scope3 on the buyer’s side.
Include lists
Restrict targeting to a hand-picked allow-list (e.g., a curated PMP of
premium publishers).
Exclude lists
Block specific domains across all of an advertiser’s campaigns (e.g., a
brand-safety blocklist).
How lists are enforced
Enforcement happens at selection time: when products are discovered and when a campaign is executed. Delivery-grain enforcement at the seller (dropping individual impressions inside an already-running buy) is not yet available.- Include lists are sent to sales agents that declare
property_listtargeting support, as atargeting_overlay.property_listreference on every package of the media buy. Sellers that do not declare support never receive the reference. - Exclude lists are enforced by Scope3 on the buyer’s side. Products whose publisher domains match the advertiser’s exclusion list are filtered out of product discovery results, and executing a campaign fails with a clear error naming the conflicting products when a selected product’s publisher is on the list. Remove those products from the buy, or remove the exclusion, to proceed. Exclusion matching is by publisher website domain; app and CTV properties without a website domain are not matched at selection time.
Concept
Each list stores a set of typed identifiers that are normalized, deduped, and resolved through two systems:- AAO registry — the cross-publisher Ad Context registry used to confirm a property is a real, identified entry.
- Local property catalog — Scope3’s mapping of identifiers to targetable
Propertyrecords used by sales agents.
resolutionSummary:
A single list can hold up to 100,000 identifiers per request. The service
chunks large inputs server-side against the AAO registry (which itself caps at
10,000 domains per call) and returns a single resource with the full
resolution summary.
Identifier types
Property lists accept AdCP-aligned typed identifiers. Pass a typed array viaidentifiers: [{type, value}], or use the domains: string[] shorthand
when every entry is a website domain.
A single mobile app can appear in a property list under multiple identifier
types (e.g.
ios_bundle AND apple_app_store_id); each resolves independently
against the AAO registry / local catalog.
domains: ["example-times.com"] is exactly equivalent to
identifiers: [{ "type": "domain", "value": "example-times.com" }]. You can pass
both fields in the same request — they’re concatenated and deduplicated.Read-side normalization.
apple_tv_bundle and ios_bundle share the
same backing column (App.bundle with appStore=APPLE_APP_STORE), so an
apple_tv_bundle write reads back as ios_bundle on subsequent GET/list
responses. The generic bundle_id fallback likewise normalizes to the
resolved app row’s store-typed form (ios_bundle or android_package).
Submit the type that best matches the AdCP property registry; expect the
response to carry the canonical store-typed form.Endpoints
All buyer endpoints below are mounted underhttps://api.interchange.io/api/v2/buyer.
The GET /lists/:listId resolution endpoint is mounted at the app root
(no /api/v2/buyer or /api/v2/storefront prefix) per ADCP convention.
All
propertyList-returning responses use the { propertyList } wrapper.
List endpoints return { propertyLists, total }.
How to use
Create an include list
Domains-only shorthand:identifiers— typed{type, value}[]actually resolved to local Property rows. Persisted as catalog membership.unresolvedIdentifiers— submitted identifiers with no matching local Property record. Transient — see persistence note below.registeredIdentifiers— identifiers found in the AAO registry but not yet locally targetable. Today onlydomainentries can land here. Transient.domains/unresolvedDomains/registeredDomains— convenience views of the above filtered totype: "domain". App identifiers are not in these.resolutionSummary— counts andresolutionRate(0..1) over the deduplicated, normalized input.
unresolvedIdentifiers and registeredIdentifiers are transient output of
the resolution call, not persisted state. They appear on create/update
responses, then drop on subsequent GETs and on name-only PUTs. Only
identifiers (the resolved set) is persisted on the list. Re-submit the
identifier set on a PUT to re-surface them.Update a list
APUT replaces the full identifier set. Active media buys that reference
this list are then notified — see Cascade behavior.
You can pass domains, identifiers, or both:
resolutionSummary and cascadeSummary whenever
identifiers change. A name-only PUT returns neither.
Validate before you commit
UsePOST /api/v2/buyer/property-lists/check to lint a candidate identifier set
against curation rules without creating anything:
Each bucket entry carries an
identifier: { type, value } field that mirrors
the input — use it to disambiguate types.
reportId (plus reportIds[] when domain input is chunked) is returned only
when at least one domain was submitted. Bundles-only and store-IDs-only
requests return no report IDs since no AAO call was made.
Cascade behavior
When youPUT an include list, every active media buy whose advertiser
references the list is notified via ADCP update_media_buy so the sales agent
can refresh its cached property set. The update response surfaces this with a
cascadeSummary:
Resolution endpoint
Sales agents resolve aPropertyListReference by calling
GET https://api.interchange.io/lists/:listId with an HMAC bearer token
that Scope3 mints when it embeds the reference in a request. This endpoint is
mounted at the app root (no /api/v2/buyer or /api/v2/storefront prefix) per ADCP convention. The
endpoint returns ADCP GetPropertyListResponse shape (not the standard
{ data, error, meta } envelope):
cache_valid_until (24 h).
Best practices
- Always inspect
resolutionSummary. Any non-zerounresolvedCountindicates identifiers that will not target — surface them to the user before going live. - Submit multiple identifier types for the same app. A mobile app is more
reliably resolved when you include both its
ios_bundleandandroid_package(and, where available,apple_app_store_id/google_play_id). Each is resolved independently against the AAO registry. - Prefer one large list over many small ones. A 100k-identifier list is
cheaper than 100 lists of 1k identifiers because each list creates its own
SmartPropertyListlink. - Use
filters.channels_anyto scope a list. Without it, the list applies across all of the brand’s targeting profiles. With it, you can keep display/OLV separate from CTV. - Treat updates as full replacements.
PUTreplaces the entire identifier set; there is no incremental add/remove. Re-send the union you want stored. - Validate before bulk import. Run
POST /api/v2/buyer/property-lists/checkon the raw input first, especially when assembling a list from spreadsheets or third-party feeds. - Avoid touching include lists during high-traffic windows. Cascading notifies every active media buy on the advertiser; schedule large updates for off-peak times when possible.
Limits
Related
Property-list briefs for sellers
What a seller’s agent receives and resolves when a buyer campaign carries a
property list.
Publisher properties and coverage
How seller coverage appears in
get_products.