Skip to main content
These endpoints give your storefront its observability surface: API Calls for what people and agents attempted, a Changes feed of who changed what, reporting metrics for every media buy that flows through your inventory sources, and a non-blocking moderation pre-check so agents can validate text before submitting it to a blocking surface. All examples use the storefront base URL:
Authenticate every request with Authorization: Bearer $SCOPE3_API_KEY. The storefront is resolved from your API key’s account context.

​
Key concepts

  • Reporting is participation-based. The storefront does not own the underlying media buys. Reporting is visible because the Merchandising Agent is the ADCP party to those transactions. The hierarchy is advertiser → media buy → package — there is no campaign level.
  • Two reporting views. summary returns a hierarchical advertiser/media-buy/package breakdown; timeseries returns flat per-day rows. Use inventorySourceId to scope to one source.
  • Activity is append-only. The audit feed records configuration and inventory-source changes. Each row attributes the actor (user or service token), records how the action was initiated (actorOrigin: human, agent, autonomous, or system) and whether it took effect (outcome: succeeded, denied, or failed), and carries the before/after changes. The default feed shows succeeded changes; filter outcome=denied or outcome=failed to audit blocked or errored attempts. Connecting a payout account (REGISTER) is included.
  • Calls and Changes are separate. GET /api/v2/activity/calls includes reads, failures, denials, latency, workload identity, and correlation IDs. GET /api/v2/storefront/audit-logs remains the semantic record of storefront mutations.
  • Activity is also in chat. Call list_storefront_activity or use /activity to open the portable Calls/Changes Page. A direct question — “which API calls failed?”, “who changed our billing?”, or “what got blocked?” — is answered from the same tenant-scoped records.
  • Moderation pre-check never blocks. It returns structured findings so an agent can self-correct. wouldBlock tells you whether the same content would trigger a 422 on a real blocking surface.

​
Debug API calls

List recent calls with the shared, tenant-scoped endpoint:
Useful filters include startTime, endTime, workloadUid, runUid, environment, outcome, operation, and surface. Continue with the opaque nextCursor returned by the API. Fetch safe detail for one authorized call at GET /api/v2/activity/calls/{activityUid}. Account admins can inspect any call in their tenant; a service token is restricted to its own stable workload. For a newly recorded MCP call, mcpHost identifies a recognized host family, such as chatgpt or claude, and records whether the hint came from MCP client information or the HTTP User-Agent. Older calls, non-MCP calls, and calls from unrecognized hosts return mcpHost: null. Host attribution is a diagnostic hint supplied by the caller, not trusted identity or authorization evidence; raw client names and User-Agent strings are not retained in this field. On the v2 storefront MCP server, list_storefront_activity opens the same Calls/Changes Page in compatible MCP Apps hosts. If the Calls rollout is not enabled for an account, the typed tool preserves the existing Changes view. In Calls, select a call and choose Ask Murph about this call to request a diagnosis through the storefront MCP server’s ask_murph tool. The widget sends the exact activity ID and displays the answer inline, without adding a chat turn. Existing account, workload, and diagnostic-detail access rules still apply.

​
Task reference

List activity

Audit feed of storefront changes

Get reporting metrics

Delivery metrics by advertiser

Check moderation

Non-blocking content pre-check

All activity tasks

Every operation in one place

Inventory sources

The sources reporting flows through

Errors

Shared error contract