Skip to main content
When a buyer submits creatives to your storefront, each one lands in your creative review queue as a pending row. You inspect the submitted creative payload and record a terminal decision: approved or rejected. Approved creatives are forwarded to the underlying sales agent verbatim; rejected ones carry your reviewer note back to the buyer. A review moves through pending → approved or pending → rejected. The revoked state — pulling a previously-approved creative — is a separate gesture and cannot be set on the decide endpoint. Each creative is identified by the AdCP creativeId the buyer supplied at submit time.

​
Buyer status and callbacks

Buyer agents submit creatives with AdCP sync_creatives. In manual-review mode the first response can return pending_review for each queued creative: 
{
  "creatives": [
    {
      "creative_id": "cr_abc123",
      "action": "created",
      "status": "pending_review"
    }
  ]
}
If the buyer calls sync_creatives again for a creative that has already been decided, the storefront returns the current decision in the per-creative status: approved with action: "updated", or rejected with action: "failed" and the reviewer note as message when one was supplied. Buyers can attach AdCP push-notification config to the original sync_creatives request: 
{
  "creatives": [
    {
      "creative_id": "cr_abc123",
      "format": "video",
      "media_url": "https://cdn.acme-brand.example/spots/launch-30s.mp4"
    }
  ],
  "push_notification_config": {
    "url": "https://buyer.example.com/adcp/tasks",
    "token": "buyer-echo-token",
    "authentication": {
      "schemes": ["Bearer"],
      "credentials": "buyer-webhook-token"
    }
  }
}
Use push_notification_config for canonical AdCP requests. The storefront also accepts pushNotificationConfig from clients that pass camelCase JSON through a REST/MCP proxy. Callback URLs must be public HTTPS endpoints; localhost, private-network, link-local, metadata, and internal hostnames are rejected. Supported authentication schemes are Bearer and HMAC-SHA256. When the operator approves or rejects the creative, the buyer webhook receives a signed ADCP task event with status: "completed" and a result.creatives[] entry whose status is approved or rejected. Rejected webhook results use action: "failed" and include the reviewer note as message when present.
The creative review row returned to storefront operators omits push_notification_config and pushNotificationConfig from submittedPayload so webhook credentials are not exposed in the queue UI or REST responses.
All examples use the storefront base URL: 
https://api.interchange.io/api/v2/storefront
Authenticate every request with Authorization: Bearer $SCOPE3_API_KEY.

​
Task reference

List reviews

GET /creative-reviews — the review queue, newest first

Get a review

GET /creative-reviews/{creativeId} — one creative review row

Decide a review

POST /creative-reviews/{creativeId}/decide — approve or reject