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
- REST API
- MCP (AI Agents)
REST API (Recommended for traditional integrations)
Standard HTTP methods with JSON request/response bodies.Production:OpenAPI Specification
Download the OpenAPI specification for SDK generation or API exploration:- Production: /api/v2/storefront/openapi.yaml
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 inPENDING 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:
Inventory Sources
Manage inventory sources within a storefront. To register an agent, create an inventory source withexecutionType: "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:
view—summary(default, hierarchical) ortimeseries(flat per-day rows)startDate/endDate— ISOYYYY-MM-DD. Falls back to the trailingdayswindow.days— Trailing window length (default7, max90,0for the full storefront timeframe)inventorySourceId— Limit to media buys flowing through a single inventory sourcedownload— Whentrue, returns a signed CSV download URL instead of JSONdemo— Whentrue, returns synthetic data (useful before live media buys exist)
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:
MCP Tools
The Storefront MCP server exposes dedicated tools for session-level actions and a genericapi_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 throughapi_call.
To operate on a different account in the same MCP session, call the dedicated customer_switch MCP tool:
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
Theapi_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.