AdCP 3.1.13 · Signals
activate_signal
activate_signal is an operation in the Signals area of AdCP 3.1.13. activate_signal is the AdCP task for pushing audience segments to DSPs and sales agents.
activate_signal request fields
The required column reflects the top-level required array only. 3 of the 11 request fields carry a top-level required flag: signal_agent_segment_id, destinations, idempotency_key. A top-level if, anyOf, oneOf or dependencies block can make an unmarked field mandatory in the mode being called, and a flat table cannot render
a rule that fires in one mode only. Those branches are visible in the request schema itself.
| Field | Type | Required | Description |
|---|---|---|---|
adcp_version | string | Release-precision AdCP version (VERSION.RELEASE, e.g. | |
adcp_major_version | integer | DEPRECATED in favor of adcp_version (release-precision string). | |
action | string | Whether to activate or deactivate the signal. One of: activate, deactivate. | |
signal_agent_segment_id | string | required | Opaque activation handle returned in the signal_agent_segment_id field of each get_signals response entry. |
destinations | destination[] | required | Target destination(s) for activation. |
pricing_option_id | string | The pricing option selected from the signal's pricing_options in the get_signals response. | |
governance_context | string | Opaque governance context returned by check_governance for this signal activation. | |
account | account-ref | Account for this activation. | |
idempotency_key | string | required | Client-generated unique key for this request. |
context | context | Opaque correlation data that is echoed unchanged in responses. | |
ext | ext | Extension object for platform-specific, vendor-namespaced parameters. |
activate_signal writes state. Its request schema is one of the 30 in the 64-entry registry flagged x-mutates-state: true. A repeated call is deduplicated only by idempotency_key, which this request requires. AdCP's release notes describe x-mutates-state as a non-normative tooling
hint that agents do not validate, so it is the registry's classification of the operation rather than
a contract, and it is the only machine-readable answer in the registry to whether an operation is
safe to retry.
activate_signal response fields
The response schema for activate_signal declares the envelope and keeps its result
in a top-level oneOf, anyOf or if, which a table of
flat rows cannot represent. The branch names are in the response schema. 29
of the 64 operations are shaped that way.
The first 13 rows are the shared protocol envelope from core/version-envelope.json and core/protocol-envelope.json. Not one of the 13 rows below belongs to activate_signal itself. One field in the whole response is marked required: status.
| Field | Type | Required | Description |
|---|---|---|---|
adcp_version | string | Release-precision AdCP version (VERSION.RELEASE, e.g. | |
adcp_major_version | integer | DEPRECATED in favor of adcp_version (release-precision string). | |
context_id | string | Session/conversation identifier for tracking related operations across multiple task invocations. | |
context | context | Per-request opaque caller-supplied correlation object echoed unchanged in the response. | |
task_id | string | Unique identifier for tracking asynchronous operations. | |
status | task-status | required | Current task execution state. One of: submitted, working, input-required, completed, canceled, failed, rejected, auth-required, unknown. |
message | string | Human-readable summary of the task result. | |
timestamp | string | ISO 8601 timestamp when the response was generated. | |
replayed | boolean | Set to true when this response was returned from the idempotency cache rather than from a fresh execution. | |
adcp_error | error | Transport-envelope error signal for fatal task failures. | |
push_notification_config | push-notification-config | Push notification configuration for async task updates (A2A and REST protocols). | |
governance_context | string | Governance context token issued by the account's governance agent during check_governance. | |
payload | object | Conceptual grouping for the task-specific response data defined by individual task response schemas (e.g., get-products-response.json, create-media-buy-response.json). |
The shared protocol envelope
62 of AdCP's 64 registered operations carry every one of the 13 envelope fields. report_plan_outcome and check_governance compose core/version-envelope.json only, so they carry the version pair and none of the task fields.
status resolves to enums/task-status.json, which admits nine values:
submitted, working, input-required, completed, canceled, failed, rejected, auth-required,
unknown. The envelope marks it required on every response, and a synchronous call emits completed rather than omitting it. When it returns submitted or working instead, task_id is the
polling handle and
push_notification_config is the webhook the agent echoes back to confirm the callback.
Webhooks are A2A and REST only: MCP sends progress notifications and defines no webhook.
payload appears in the response field table typed object. core/protocol-envelope.json describes it as a documentary construct and states that it is not a required wire field. Body fields
are siblings of the envelope fields: on MCP at the root of the tool response, on A2A in task.artifacts[0].parts[].DataPart, on REST at the root of the JSON body. An accessor that reads response.payload finds
nothing there.
Field lists are not published over the wire
AdCP's integration guide, docs/protocol/calling-an-agent.mdx, states that its MCP
servers no longer publish per-tool parameter schemas: a tools/list call returns an empty
properties object for every tool, and the guide directs clients not to infer shape from it. A client
author reads the schema registry instead of the tool list.
Example activate_signal calls
The field tables above come from the 3.1.13 schema release and these blocks come from the documentation tree, which is versioned separately, so the two can disagree.
{
"deployments": [
{
"type": "platform",
"platform": "string",
"account": "string",
"activation_key": {
"type": "segment_id",
"segment_id": "string"
},
"estimated_activation_duration_minutes": "number",
"deployed_at": "string"
}
],
"errors": [
{
"code": "string",
"message": "string",
"field": "string",
"suggestion": "string",
"details": {}
}
]
}{
"type": "segment_id",
"segment_id": "ttd_segment_12345"
}{
"type": "key_value",
"key": "audience_segment",
"value": "luxury_auto_intenders"
}Frequently asked
- What does activate_signal do?
- activate_signal is the AdCP task for pushing audience segments to DSPs and sales agents.
- Which fields does a activate_signal request require?
- 3 of the 11 request fields carry a top-level required flag: signal_agent_segment_id, destinations, idempotency_key. AdCP also constrains requests with top-level if/then, anyOf, oneOf and dependencies blocks that no required array captures, so an unmarked field can still be mandatory in the mode being called.
- Which AdCP version do these activate_signal field tables describe?
- AdCP 3.1.13, the current published release, last updated 2026-08-11. The documentation tree is versioned separately from the schema tree in the same repository, so a doc page and a schema file can describe the same field differently.