Skip to main content

get_creative_features

Evaluates a creative manifest and returns feature values from a creative governance agent.

Use cases

  • Security scanning: Detect malware, auto-redirects, credential harvesting, cloaking
  • Creative quality: Evaluate brand consistency, platform optimization, guideline adherence
  • Content categorization: Classify creative content against IAB Content Taxonomy or other standards
  • Accessibility: Check WCAG compliance, screen reader compatibility

Request

Parameters

Retry and reconciliation contract

get_creative_features can allocate provider compute, an evaluation record, consumption, and cost metadata even when the caller-facing price is zero. To preserve 3.x wire compatibility, idempotency_key is optional until AdCP 4.0, but clients SHOULD send one for every logical evaluation. When a key is supplied to a provider that advertises replay support, the provider MUST retain its replay record for at least 24 hours. An unkeyed 3.x request remains valid, but cannot be retried safely after an ambiguous result.
  • With a supplied key, the same key and the same RFC 8785 canonical payload returns the cached initial response with replayed: true. The provider performs no second evaluation and records no second consumption or charge.
  • Reusing a supplied key with a different creative_manifest, account, or feature_ids payload returns IDEMPOTENCY_CONFLICT. Array order remains significant; feature_ids does not receive set-like canonicalization.
  • For a keyed request, context is opaque echo data: it is excluded from the canonical replay hash and MUST NOT be used as a replay fence. Changing only context does not authorize a new evaluation.
  • An in-flight keyed duplicate follows the provider’s declared wait-and-replay policy or returns IDEMPOTENCY_IN_FLIGHT. Callers retry with the same key after error.retry_after; they MUST NOT mint a new key.
  • Replaying a keyed async request returns the original submitted acknowledgement with the same task_id and, when present, the same evaluation_id. Poll task_id for current state.
Providers advertise replay support through adcp.idempotency in get_adcp_capabilities. A client MUST treat an omitted key, supported: false, or a replay window below 24 hours as unsafe for automatic get_creative_features retry. After an ambiguous timeout it must fail closed and reconcile out of band rather than minting a new key.

Authentication when used as a build evaluator

get_creative_features is also the evaluator contract used when build_creative.evaluator.agent_url or build_creative.evaluator.feature_agent.agent_url points at an external evaluator. In that flow, the creative/seller agent is the caller and the evaluator authenticates it on the transport: RFC 9421 request signing with JWKS discovery is preferred, and mTLS or a pre-provisioned Bearer/API-key credential are acceptable when both parties have arranged them. The request payload is not an authentication channel. Evaluators MUST NOT treat agent_url, account, context, ext, or fields inside creative_manifest as proof of caller identity, and callers MUST NOT put evaluator credentials or caller-supplied trust material in those fields. Credential- or trust-material payload keys such as api_key, client_secret, bearer, authorization, jwk, jwks, or jwks_uri are non-conforming and should be rejected with CREDENTIAL_IN_ARGS. After authenticating the transport, the evaluator maps the caller to its allowed creative agent/account configuration. A request signed by, or carrying credentials for, an unrecognized creative agent should fail authentication or authorization; it should not be accepted because the payload names an expected account. When this call was initiated by build_creative and the evaluator is unreachable or rejects the producing agent’s transport authentication, the buyer-visible build should fall back to seller-default ranking with an advisory errors[] note rather than failing solely because evaluation was unavailable.

Response

Response fields

feature_ids filters results[]; audit_observations[] may still appear when the submitted provenance itself is audit-worthy. OVERSIGHT_DISCLOSURE_CARVEOUT_CLAIMED fires when human_oversight is edited or directed and disclosure.required is false; verifier observations such as observed_value and confidence are optional audit context.

Error response

Async evaluation

Some evaluations (for example, sandboxed malware scanning) take time. After accepting the work, the provider returns status: "submitted" and a pollable task_id. In 3.x, providers SHOULD also include the provider-generated evaluation_id; it becomes required in 4.0. The caller can always poll get_task_status; when the request included push_notification_config, the provider also delivers at least the terminal completion or failure notification. When the acknowledgement includes evaluation_id, the terminal success artifact MUST repeat it. Any pricing_option_id, vendor_cost, currency, and consumption values are part of that terminal artifact. detail_url is optional and is not an evaluation identity or reconciliation key. An exact keyed replay while the evaluation remains async returns the original submitted acknowledgement with replayed: true, the same task_id, and, when present, the same evaluation_id; it does not return current task state. Poll the task for current state. This uses the standard async task pattern.

Orchestrator logic

The orchestrator applies feature requirements on the client side, the same way property list feature requirements work:

Relationship to property governance

Creative governance follows the same pattern as property governance: