Skip to main content

Storefront API Reference

Overview

The Interchange Storefront API provides capabilities for publishers and technology partners to set up and manage storefronts, configure inventory sources, register agents, and handle billing through both REST and MCP (Model Context Protocol) interfaces.

Connection Methods

Standard HTTP methods with JSON request/response bodies.Production:
Example:

OpenAPI Specification

Download the OpenAPI specification for SDK generation or API exploration:

Authentication

All API requests require authentication using your Interchange API key:

Get API Key

Request API credentials to get started

Storefront Capabilities

The Storefront API provides access to:
  • Storefronts — Create, view, update, and delete storefronts
  • Inventory Sources — Manage inventory sources and register agents within storefronts
  • Reporting — Delivery metrics for every media buy your Merchandising Agent is a party to through your Storefront inventory sources (advertiser → media buy → package)
  • Billing — payout bank details, fee configuration, and payment terms

REST API Endpoints

Storefronts

Manage storefronts for your publisher integration. Each account has exactly one storefront, which is automatically created in PENDING when the seller signs up — POST /api/v2/storefront is idempotent and returns the existing storefront if one is already provisioned. There is no delete endpoint; storefronts are activated or disabled via PUT. Creating a storefront requires both a name and a publisherDomain (a valid domain such as acme.com). The publisher domain is the identity buyers and partners look your storefront up by — it connects your inventory to buyer demand. Existing storefronts are unaffected; only new create requests must supply it. Example — Configure Storefront:
Example — Check Readiness:

Inventory Sources

Manage inventory sources within a storefront. To register an agent, create an inventory source with executionType: "agent" and provide the agent’s endpoint URL and protocol. Modular inventory sources (executionType: "MODULAR_SOURCE") are composed from source-side modules such as inventory feeds, booking ledgers, trafficking integrations, status sync, reporting imports, and human-in-the-loop work queues. Use the modular projection endpoint to inspect module contracts, lifecycle stages, automated/HITL/unsupported modes, missing setup fields, and open source work items. The projection reports setup-state and configuration completeness; it does not guarantee that runtime media-buy inputs, upstream booking, trafficking, or human review are complete. The module config endpoint writes non-secret module configuration only. It can set manual module states such as CONFIGURING, DISABLED, or ERROR, but it cannot set ACTIVE; active execution state is derived by the execution workflow. Example — Register an Agent as an Inventory Source:

Reporting

Delivery reporting for every media buy your Merchandising Agent is a party to through your Storefront inventory sources. The Storefront account does not own the underlying media buys — these are buyer-side campaigns flowing through your inventory sources — but you have visibility because your Merchandising Agent participates in each transaction. Hierarchy: advertiser → media buy → package (no campaign level). Query parameters:
  • viewsummary (default, hierarchical) or timeseries (flat per-day rows)
  • startDate / endDate — ISO YYYY-MM-DD. Falls back to the trailing days window.
  • days — Trailing window length (default 7, max 90, 0 for the full storefront timeframe)
  • inventorySourceId — Limit to media buys flowing through a single inventory source
  • download — When true, returns a signed CSV download URL instead of JSON
  • demo — When true, returns synthetic data (useful before live media buys exist)
Example — Last 7 days, summary view:
Example — Time-series for one inventory source:
Example — CSV export:

Storefront Billing

Payout bank details and fee configuration for storefronts. Interchange pays sellers by bank transfer using the payout details on file; normal storefronts use Interchange-cleared (agent) settlement today. Seller-cleared settlement is planned but is not yet configurable. Example — Set payout details:
Example — Get billing configuration:

MCP Tools

The Storefront MCP server exposes dedicated tools for session-level actions and a generic api_call tool for REST operations. Use the dedicated MCP tool when one exists. Use api_call for storefront REST operations that do not have a more specific tool. Every api_call requires a named operation; the legacy raw method + endpoint form is no longer supported and is rejected.
Required workflow for AI agents: Choose the most specific MCP tool first. For account context, call customer_switch directly instead of routing through api_call. For REST operations, call ask_about_capability first when unsure of the exact interface, then call api_call with an operation name. Field names are camelCase (e.g. agentId, not agent_id).

Switch Account

Account switching is session state. It is not a per-call REST parameter and is not available through api_call. To operate on a different account in the same MCP session, call the dedicated customer_switch MCP tool:
After switching, retry the original api_call without customerId in params or body. If the target account is not available to the current MCP session, re-authenticate with that account’s credentials.

Supported Endpoint Families

The api_call tool allows access to: Use get_current_account and list_accounts to inspect the active account and the account IDs available before calling the dedicated customer_switch tool.

Response Format

All responses follow a consistent structure:
Error Response:

Support

For technical support, contact us at support@scope3.com.