Getting data out
There is no analytics API to start against, so this is not a quick-start against an endpoint. It is the decision you have to make first: where the query side of your analytics is going to live.
Three shapes work today. Most real integrations use two of them together.
1. Subscribe to events
Commerce activity is published as events. Subscribe, and you get the stream of what happened — orders placed, carts abandoned, prices changed — which is the raw material for any metric you want to compute on your side. This is the lowest-latency path and the one to use when your analytics needs to react rather than report.
See Events for the event catalogue and subscription model, and Webhooks to have that activity delivered to an HTTPS endpoint you own. The reporting-specific angle — which events carry reporting value, what the delivery guarantees do to your numbers — is Stream commerce activity.
Choose it when you need freshness, an alert, or a running counter. Do not choose it alone. A stream cannot answer "what was last quarter" if you were not listening last quarter.
2. Pull from the commerce API and keep your own store
Every commerce entity you would want to report on — products, orders, carts, payments, customers — is readable through the public API. Page through it on a schedule, land it in your own warehouse or database, and query it with your own tooling. Nothing about the platform assumes you will do reporting inside it.
The mechanics that matter here are pagination, filtering and rate limits, all of which are the same across every endpoint: see API usage. Browse the endpoints in the API Explorer.
Choose it when you need history, joins across entities, or a number somebody will argue about. This is the path that ends up authoritative for most partners — see Build your own reporting store.
3. Ship an analytics.json with your App
If you are building an App, you can declare which of your own tables are analysable and how. The platform compiles those declarations into datasets in the tenant's Analytics Studio, so an operator can chart and segment your app's data alongside the platform's own — without you building any reporting UI.
This is the only part of Analytics Studio with a public, versioned contract. See Make your app's data analyzable.
Choose it when the audience is the tenant's operator, not your own application. Note what it is not: it does not give you a query API over your app's data. It puts your data in front of the operator, in Cockpit.
Choosing
| You want | Path |
|---|---|
| A number in your own product's UI | 2 (your own store), fed by 1 |
| An alert when something happens | 1 (events) |
| A dashboard the tenant's staff use | 3 (analytics.json) |
| A quarterly report somebody signs off | 2 (your own store) |
| To reconcile a disputed figure | 2, re-read from the API |
The combination that holds up: events for freshness, the API for truth, analytics.json for the operator.
What you should not plan around
Before you design anything, read What does not exist yet. The short version: there is no analytics or metrics API, no embeddable dashboard, no guest-token flow, no metric-definition API, no funnel builder, no forecasting, no scheduled export delivery, and no warehouse you can query.
If your plan requires any of those, it requires you to build it — on your side, from the two feeds above.
Where to go next
- Stream commerce activity — the events path, from a reporting angle.
- Build your own reporting store — pull, backfill, sync, model.
- Make your app's data analyzable — the shipped contract.
- Designing for what's coming — choices that stay right when more of this lands.