/api/v2/storefront/esa/{esaId}/signals
The ad-server signal endpoints let a storefront operator build and
manage the signals a seller builds from targeting in an ad server source. The /esa/
path segment and esaId field are stable API identifiers; the operator-facing
object is an ad server source.
Keep these two layers distinct:
Browsing ad-server targeting does not create or import a signal. It
shows the raw material available for authoring.
Start every authoring workflow by reading source capabilities. Capabilities
describe which mapping kinds, API candidate types, value types, composition
models, and parent-filtered types the source supports. Do not assume every ad
server source supports GAM fields. When a selected targeting candidate includes
defaultSignal, use that complete draft as the starting point instead of
reconstructing its adapter mapping.
Endpoints
Bulk signal creation with Murph
When you need to create many signals, ask Murph to create them as a batch instead of one by one. Murph still validates and previews the proposed signals before any durable write, and the confirmation gate still fires before creation. The batch is approved once, then Murph creates the set together.- Paste a list or upload rows. Murph maps each row to the source’s supported signal shape after reading source capabilities.
- One approval for the batch. You review the full set and approve once rather than approving every signal individually.
- Continues on error. If one signal fails, the rest continue. Murph reports a per-signal result so you can retry only the failures.
Source capabilities
Capability fields
Browse ad-server targeting
Ad-server targeting records are source-native values that can be used to build a signal draft. The endpoint returns them in acandidates array;
that is the wire name, not a separate operator-facing object. For hierarchical
API types, first browse the parent type and then pass its externalId as
parent_id when browsing the nested type.
defaultSignal is the adapter-authored complete draft for that targeting
candidate. Use it directly for validation, changing only signalId or name
when the seller needs different buyer-facing wording. Validate again after any
change.
Ad-server targeting query parameters
Signal draft shape
Creation and validation use the same request body:How signals relate to products
Products describe the sellable inventory package. Signals describe targetable attributes that can be exposed to buyers or used in targeting workflows. For GAM key-values, do not treat “not in the product selector fields” as “not supported.” Key-value signal targeting is supported when the source capabilities advertise the relevant signal mapping kind. Usecustom_key_value for a direct key/value mapping and
gam_targeting_groups for composite GAM key-value logic. Then validate the
signal and use it according to the adapter’s targetingSemantics. If
targetingSemantics.mappingKinds[].exclusiveWithOtherSignals is true for
gam_targeting_groups, use that grouped signal by itself for the buyer
targeting field it consumes.
Some large networks use GAM key-values to identify site lists or other
seller-defined groups inside their network. Those keys and values are
browseable as ad-server targeting and can be used to create signals.
Publisher coverage still comes from
adagents.json. Buyer property-list references are forwarded and resolved
today; the seller’s agent decides whether and how to map the requested subset to
products or ad-server controls. See
Custom targeting and properties.
Audience segment
Direct GAM key-value signal
Use a directcustom_key_value signal when the adapter exposes a specific
custom targeting value as directly mappable. Browse values with parent_id so
the value remains tied to the correct key.
Grouped GAM targeting
Usegam_targeting_groups for composite GAM logic. Groups are OR’d together;
criteria inside a group are AND’d together; multiple values inside one criterion
are OR’d by GAM for that key. A criterion with exclude: true excludes matching
values.
Grouped GAM targeting can be exclusive depending on the adapter semantics. If
targetingSemantics.mappingKinds[].exclusiveWithOtherSignals is true, do not
combine the grouped signal with another signal targeting the same buyer field.
Validate a signal draft with dry_run=true
Use POST /api/v2/storefront/esa/{esaId}/signals?dry_run=true to validate and
preview a signal draft without persisting it. The request body is the same as
POST /signals, but the response is a validation result rather than a saved
signal object. Read the valid flag, not the HTTP status — a dry run returns
200 even when the draft is invalid, and the issues[] array explains why. A
malformed request body still returns 422.
preview with the rendered wire signal and source projections. Use a dry
run before create when a client is assembling adapterConfig manually, or before
update to preview a change.
Create a signal
List and get signals
signalId and name; sources can
return additional fields such as description, status, valueType,
adapterConfig, coverageForecast, createdAt, and updatedAt.
Errors
400 VALIDATION_ERROR— invalid ad server source id, malformed draft, missing required fields, or a source validation issue.401 UNAUTHORIZED— missing or invalid bearer token.404 NOT_FOUND— ad server source or signal does not exist for the caller.502or503— the ad server source or its upstream service could not complete the request.
Related
Storefront signal tasks
Create and manage storefront signals
Custom targeting and properties
How GAM key-values relate to site lists and publisher coverage
Signal overview
Signal model and lifecycle
Storefront API reference
OpenAPI reference for storefront routes