Optionalcontext_id?: stringTransport-managed conversation identifier. On A2A, this maps to the native Message/Task contextId used to associate messages with a conversation; it is not carried inside the AdCP DataPart. On MCP, a request-body context_id, where admitted by the selected request schema, is a compatibility-only field: servers MUST ignore it, callers MUST NOT rely on it for continuity, and it MUST NOT select session state, identity, account, authorization, task continuation, or idempotency scope. MCP continuity, if provided, comes from the transport session. Distinct from context (per-request opaque echo, see below) and from task_id (AdCP operation tracking).
Optionalcontext?: ContextObjectOptionaltask_id?: stringUnique identifier for tracking asynchronous operations. Present when a task requires extended processing time. Used to query task status and retrieve results when complete.
Optionalmessage?: stringHuman-readable summary of the task result. Provides natural language explanation of what happened, suitable for display to end users or for AI agent comprehension. Generated by the protocol layer based on the task response.
Optionaltimestamp?: stringISO 8601 timestamp when the response was generated. Useful for debugging, logging, cache validation, and tracking async operation progress.
Optionalreplayed?: booleanSet to true when this response was returned from the idempotency cache rather than from a fresh execution. Set to false (or omitted) when the request was executed fresh. Buyers use this to distinguish cached replays from new executions — matters for billing reconciliation, audit logs, state-machine routing (cached state-tracking fields are historical snapshots, not current state — re-read via the resource's read endpoint), and any downstream system that assumes exactly-once event semantics. replayed appears only when the request actually resolved through the idempotency cache. Pure reads may ignore an optional idempotency_key; when a seller voluntarily caches keyed reads, those responses use the same replay indicator and full cache contract.
Optionaladcp_error?: ErrorOptionalpush_notification_config?: PushNotificationConfigOptionalgovernance_context?: stringOpaque authorization context issued only by an approved check_governance decision. Buyers attach it to governed requests across protocol roles (media buys, rights acquisitions, signal activations, creative services); receiving services persist it and forward it on subsequent execution and lifecycle checks. The context is the authoritative plan binding at service boundaries, so a service MUST NOT require a separate plan_id.
Governance agents MUST emit a compact JWS per the AdCP JWS profile. Verifiers validate standard authorization claims such as signature, issuer, audience, expiry, and replay protection, but intermediaries MUST NOT interpret embedded governance state for business logic. A conditions or denied verdict never carries an authorization context.
This is the primary correlation key for audit and reporting across the governance lifecycle.
Optionalpayload?: {}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). payload is a documentary construct — it is NOT a required wire field, and its on-the-wire shape depends on transport (see Transport serialization below). Task response schemas declare body fields without wrapping them in a payload object; the wire representation places those body fields per transport convention. On MCP the body fields appear as siblings of envelope fields at the root of the tool response; on A2A they appear inside task.artifacts[0].parts[].DataPart; on REST they appear at the root of the JSON body.
Optionaladcp_version?: stringRelease-precision AdCP version (VERSION.RELEASE, e.g. "3.0", "3.1", "3.1-beta"). On a request: the buyer's release pin — the seller validates against its supported_versions and returns VERSION_UNSUPPORTED on cross-major mismatch, or downshifts to the highest supported release within the same major. On a response: the release the seller actually served — clients SHOULD validate the response against that release's schema, not against their pin. Patches are not negotiated; surface them as build_version on capabilities for operational visibility. When omitted, falls back to adcp_major_version (deprecated) or server default. Buyers SHOULD emit both adcp_version and adcp_major_version through 3.x to remain compatible with sellers that only read the legacy field. NORMALIZATION: SDKs that read full-semver values from bundle metadata (e.g. ComplianceIndex.published_version = "3.1.0-beta.1") MUST normalize to release-precision ("3.1-beta.1") before emitting on the wire — meta-field values are NOT valid wire values.
Optionaladcp_major_version?: numberDEPRECATED in favor of adcp_version (release-precision string). Servers MUST continue to honor this field through 3.x. Removed in 4.0. Original semantics: the AdCP major version the buyer's payloads conform to. Sellers validate against their supported major_versions and return VERSION_UNSUPPORTED if unsupported. When omitted, the seller assumes its highest supported version.
Optionalview?: ReportingStatusViewOptionalledger_snapshot_id?: stringOpaque identity of the seller's consistent reporting-ledger snapshot. Every page reached from one periods cursor MUST return the same value.
Optionalledger_as_of?: stringExclusive observation boundary for ledger_snapshot_id. Revisions committed later appear only in a later reconciliation.
Optionalchanges_checkpoint?: stringOpaque durable incremental-repair checkpoint for this periods snapshot. Consumers persist it only after consuming every page, then send it as changes_after. It is bound to authenticated caller, account, and filters and MUST order every committed obligation, revision, adjustment, materialization, consumer status statement, revision receipt, and adjustment receipt without gaps.
Optionalaccount_id?: stringResolved seller/storefront account identifier.
Optionalscope?: {Exact denominator evaluated for summary or periods health. complete is valid only when scope_closed is true.
True only when no new obligation can enter this evaluated scope.
Optionalmedia_buy_ids?: ReportingMediaBuyID[]True when media_buy_ids was omitted and the scope covers all caller-accessible account buys.
Exact independently reconciled configuration generations in the denominator.
Earliest period boundary for which anti-entropy metadata is retained for every selected configuration generation.
Whether the requested horizon is fully inside retained ledger coverage. False means health cannot prove completeness for the whole requested horizon.
Optionalhealth?: ReportingHealthOptionalcoverage?: ReportingCoverageOptionaldata_through?: string | nullConservative latest included event time across satisfied obligations in scope, or null when unavailable/unknown.
Optionalnext_expected_at?: stringNext obligation due time for an open scope. In a complete summary (view: summary, health: complete), the nearest future period start, strictly after ledger_as_of, across all active committed configuration generations in scope.delivery_config_generations. Sellers MUST populate it when such a scheduled period exists outside the closed evaluated scope, and omit it when none exists. This complete-scope projection applies only to summary responses. It is derived from the configuration schedule and does not represent an open obligation in the evaluated scope; its presence does not indicate that the scope is still open. Projecting it MUST NOT create, expose, lease, count, or alter an obligation whose period has not closed, or change obligation_counts, scope, or coverage. Obligation expected_at remains period.end plus schedule.delivery_sla; get_media_buy_delivery.next_expected_at remains the next webhook notification time.
Optionalobligation_counts?: {Optionalconsumer_status_pending?: numberObligations in this scope whose elapsed expected period has passed its consumer-status deadline — expected_at plus automated_recovery_window_seconds — without a current consumer status from the authenticated caller. A chain with any unsuperseded leaf counts as current whatever that leaf says; only an empty chain is pending. Because it counts obligations, a period the seller omitted entirely has no obligation and is not counted here — the buyer's independently derived denominator, not this field, remains the authority on omitted periods. It is a visibility count over the caller's own silence, never a health input: it MUST NOT change health, any other count, or seller-advertised reliability_statistics, and it overlaps the health counts rather than partitioning them. Required when the seller advertises consumer_status_task.
Optionalissues?: ReportingStatusIssue[]Optionalperiods?: ReportingObligation[]Optionalrevisions?: ReportingRevision[]Revision ledger records on this page. Pagination is over the flat union of obligations, revisions, adjustments, materializations, consumer status statements, revision receipts, and adjustment receipts, avoiding unbounded nested history.
Optionaladjustments?: ReportingAdjustment[]Immutable post-official accounting corrections on this page. They preserve the original invoice-to-revision binding and are included in flat ledger pagination.
Optionalconsumer_statuses?: ReportingConsumerStatus[]Authenticated caller's append-only reporting status history on this page. Current leaves are identified by obligation current_consumer_status_id or, for a missing seller obligation, by the supersession chain over configuration generation, report definition, and period. No other consumer's status is disclosed.
Optionaladjustment_receipts?: ReportingAdjustmentReceipt[]Authenticated Reconciled Billing outcomes for adjustments on this page.
Optionalpagination?: PaginationResponseOptionalrevision?: ReportingRevisionOptionalmaterializations?: ReportingMaterialization[]Optionalreceipts?: ReportingReceipt[]Authenticated caller's durable reconciliation receipts. Receipts from another consumer principal are never disclosed.
Optionalerrors?: Error[]Optionalext?: ExtensionObject
Authoritative caller/account-isolated reporting status response. The view echoes the request and discriminates summary, periods, exact revision, and fatal error shapes. Seller obligation/revision state and separately attributed consumer status remain distinct but are compared in the caller-scoped health projection. Every identifier, cursor, ledger snapshot, destination, revision, materialization, consumer status, and resource is scoped to the authenticated caller and account.