Ad Platform Resource Capabilities

When Scope3 reads audiences, signals, or event sources from a connected ad platform account (see Connecting Ad Platform Accounts), what comes back depends on the platform. Some platforms return the account’s complete inventory. Others can only see objects that were created through Scope3, or return a single derived entry rather than a real inventory read. This page documents that coverage per platform so you know when a result is the whole picture and when it is not.

​

Reading the tables

Each read falls into one of three coverage classes: Two more distinctions matter when interpreting any of these reads:

• Discovery is not attachment. These reads answer “what exists in the account right now” by asking the platform directly. An object appearing in a discovery read does not mean it is attached to, or usable by, any particular campaign — and an object synced through Scope3 remains tracked even if a later discovery read cannot see it.
• Only a full-inventory read is authoritative. A synthesized or seller-managed result is still real data, but absence from it proves nothing about the account. Never treat a partial read as evidence that an object does not exist.

​

Audiences

Audience inventory is read with a discovery-mode sync_audiences call (no audience list supplied, so nothing is created or modified). No audience membership data is ever returned — identity, status, and match counts only.

​

Audience write and deletion boundaries

Inventory coverage does not imply that every platform supports the same write lifecycle. Scope3 advertises only the operations that the official adapter can confirm against the provider: The governed staging lifecycle exercises the full create, target-in-a-paused-buy, update, and crash-safe delete path for Google Ads, Meta, Snap, and Reddit. TikTok runs that same path only inside its signed, bounded staging probe; it does not advertise ordinary audience targeting until the resulting evidence is complete and signed. Adapters with a boundary above remain fail-closed instead of inheriting that parity claim.

​

Signals

Signals are read with get_signals, a read-only projection of the platform’s audience inventory into AdCP signal references. Pinterest does not synthesize a fallback signal: an empty provider inventory stays empty, and an account or provider error fails the read. Signal coverage follows the platform’s audience coverage above.

​

Event sources

Event sources (pixels, tags, conversion actions) are read with a discovery-mode sync_event_sources call. No event payloads are returned. Setup code is included only where the platform supplies that exact account-scoped artifact. Seller-managed entries describe measurement the platform performs natively. Synthesized entries confirm the platform’s tagging surface exists for the account but say nothing about which tags are actually installed. LinkedIn conversion rules are managed in LinkedIn Campaign Manager, not through Scope3. sync_event_sources reads each enabled CONVERSIONS_API rule the account already has and maps its LinkedIn conversion type to the closest AdCP event_type (an unrecognized or newly introduced LinkedIn type maps to custom, named after the conversion rule, rather than failing the read). Insight Tag rules remain valid for native campaign optimization and association, but are not returned by this direct-event sync and logging surface. A disabled rule that is explicitly requested by event_source_id fails with EVENT_SOURCE_DISABLED instead of being silently synced. Creating, renaming, or deleting a conversion rule through sync_event_sources is not supported and fails with CONVERSION_RULE_MUTATION_UNSUPPORTED or EVENT_SOURCE_UPDATE_UNSUPPORTED — manage the rule itself in Campaign Manager, then re-sync to pick up the change. log_event accepts events only for a rule that is enabled and owned by the selected account, and rejects an event whose type does not match the rule’s mapped event_type. A full-inventory sync_event_sources call (no event_sources in the request) fails with LINKEDIN_EVENT_SOURCE_DISCOVERY_TOO_LARGE for an account with more than 500 enabled CONVERSIONS_API rules, instead of silently returning only some of them — request the specific event_source_id you need instead of full discovery on an account that large. Pinterest treats the ad account and Conversion Tag as separate identities. Scope3 rejects request-account mismatches before Pinterest I/O, validates every returned Tag against the selected account, and relays executable setup only when Pinterest returns that Tag’s personalized code_snippet. A missing, malformed, duplicate, or cross-account inventory fails closed. Server-side Pinterest event delivery remains unavailable until the signed dedicated-account validation is complete. Existing Tags can be revalidated through sync_event_sources; changing or removing Pinterest Tag configuration is not supported and fails visibly. Successful discovery returns the complete inventory and is never truncated. Pinterest responses are limited to 500 Tags and 256 KiB, and the complete projected result is limited to 128 KiB. If any limit is exceeded, the operation fails before replacing the last proven binding snapshot.

​

Commerce catalogs and product sets

Meta Sales — Website Catalog Sales discovers every commerce catalog owned by the selected account’s Business Portfolio, then reads every product set in each catalog. A catalog is offered only with non-empty product sets, and each product-set candidate retains its parent catalog identity. These are activation resources for meta_sales_website_catalog, not audience signals. The read is fail-closed: missing Business Portfolio context, incomplete pagination, invalid ownership data, or a product set returned under a different catalog makes the resource inventory unavailable rather than producing a partial candidate list. Creation repeats the provider read before mutation.

​

Related