Skip to main content

Overview

Sandbox mode lets buyers test the full media buying lifecycle — discovery, campaign creation, creatives, and delivery — without real platform calls or spending real money. Responses contain simulated but realistic data. Sandbox is account-level, not per-request. Once a request references a sandbox account, the entire request is treated as sandbox. This eliminates the risk of accidentally mixing real and test traffic in a multi-step flow.

Capabilities discovery

Sellers declare sandbox support in get_adcp_capabilities:
Check this before using sandbox mode. If account.sandbox is not declared or is false, the seller does not support sandbox.

Two paths to sandbox

How you enter sandbox mode depends on the seller’s account model (require_operator_auth). The two paths are completely different — make sure you follow the right one.

Implicit accounts (require_operator_auth: false)

The seller trusts the agent and does not require per-operator authentication. Sandbox is part of the natural key — the same brand/operator pair can have both a production and a sandbox account, distinguished by sandbox: true. Setup: Declare a sandbox account via sync_accounts with sandbox: true on the account entry:
Usage: Reference the sandbox account by natural key with sandbox: true on every request:

Explicit accounts (require_operator_auth: true)

The seller requires each operator to authenticate directly. Sandbox accounts are pre-existing test accounts on the seller’s platform — think Stripe test mode, Google Ads sandbox accounts, or Snap test advertiser accounts. You do not create them; you discover them. Setup: Discover sandbox accounts via list_accounts with the sandbox: true filter:
The seller returns pre-existing test accounts:
Usage: Reference the sandbox account by account_id on every request:

Quick reference

Response confirmation

Success responses include sandbox: true to confirm the request was processed in sandbox mode:

Full lifecycle example (implicit account)

This example shows the implicit account path. For explicit accounts, replace the natural key account reference with { "account_id": "acct_sandbox_acme_001" } in each step.

1. Discover products

2. Create a media buy

The seller returns a simulated media buy with realistic IDs, packages, and creative deadlines — nothing is booked on any real platform.

3. Upload creatives

4. Check delivery

The seller returns simulated delivery metrics — impressions, spend, pacing — as if the campaign were running.

Sandbox vs dry run

Some tasks (e.g., sync_creatives) also support a dry_run parameter. These serve different purposes:

Seller implementation

When a request references a sandbox account (either via sandbox: true in the natural key or via a sandbox account_id):
  • Do not make real ad platform API calls (no real orders, line items, etc.)
  • Do not charge real money or create real billing records
  • Do validate inputs the same way as production (reject invalid budgets, bad dates, etc.)
  • Do return realistic response shapes with simulated data
  • Should include sandbox: true in success responses
Sandbox errors are real validation errors. If a buyer sends an invalid budget using a sandbox account, return a real error — don’t simulate fake errors. For explicit account sellers: ensure your platform has pre-existing sandbox/test accounts that list_accounts can return when filtered with sandbox: true. For implicit account sellers: accept sandbox: true as part of the natural key in sync_accounts and account references. Treat (brand, operator, sandbox: true) as a distinct account from (brand, operator).

Protocol compliance

Sellers that declare account.sandbox: true in capabilities MUST:
  • Accept sandbox accounts appropriate to their account model
  • Apply sandbox semantics to all requests referencing a sandbox account
  • Apply normal input validation (sandbox does not bypass validation)
Sellers SHOULD include sandbox: true in success responses when processing a sandbox account request.