Reports

Sales are written by the point of sale, not by the API. What the partner surface gives you is the same aggregation the merchant sees in their back office, computed server-side. Reading four report endpoints is always cheaper and more accurate than paging thousands of sale rows and adding them up in your own code.

Endpoints

Method	Path	Scope	Row grain
GET	/v1/reports/business-summary	reports.read	Totals for the window
GET	/v1/reports/items	reports.read	One row per item sold
GET	/v1/reports/pay-types	reports.read	One row per payment type
GET	/v1/reports/sales	reports.read	One row per sale
GET	/v1/reports/daily-sales	adsr.read	One row per store per day

Parameters

Parameter	Type	Required	Notes
from	string	yes	YYYY-MM-DD, inclusive
to	string	yes	YYYY-MM-DD, inclusive
storeId	number	no	Omit for every store the token can see
page, limit	number	no	On row-level reports. limit maximum 100

curl -s "$API_BASE_URL/reports/business-summary?from=2026-07-01&to=2026-07-31&storeId=1" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Dates are store-local trading dates

A report window is expressed in the merchant’s own trading calendar, not UTC. A sale rung up at 01:40 during a late shift belongs to the trading day the store was in, which is why these endpoints take dates rather than timestamps.

Choosing a report

Business summary answers “how did this period go?” — sales, tax, discounts, refunds and transaction counts for the whole window, optionally for one store. It is the right call for a dashboard tile or a nightly digest.

Items answers “what sold?” — one row per item with quantity and value, ordered by value. Use it for range reviews, supplier reporting and reorder suggestions.

Pay types answers “how did people pay?” — one row per payment type with the count and value taken. Use it for reconciliation against acquirer settlements.

Sales is the row-level list, one entry per completed sale, paged. Reach for it only when you genuinely need individual transactions — an accounting export, an audit trail — not to compute totals.

Need a stable machine contract?

GET /v1/reports/daily-sales returns a fixed, versioned row shape — one canonical row per store per day. Where the four reports above mirror the back office’s own column sets, daily-sales is a contract designed for machines. If you are building an automated feed, use it. See the ADSR feed.

Field schemas

The four back-office reports return the same columns the merchant sees in the product, and those column sets differ per report and per region’s tax model. The exact schema for each is published in the Full API reference, generated from the service that produces it — read it there rather than inferring from a sample.

Every report uses the standard envelope:

{
  "data": [ /* rows */ ],
  "meta": { "page": 1, "limit": 100, "total": 412 }
}

Summary-grain reports return a single object in data and omit meta.

Practical guidance

• Window size. daily-sales is capped at 31 days (partner.window_too_large). The other reports accept longer ranges, but a month at a time keeps responses small and cacheable.
• Cache by closed day. Yesterday’s numbers do not change once the trading day is closed. Cache them and only re-pull today.
• Refunds are negative movement, not deletions. A refunded sale stays in the sales list; the refund reduces net totals. Never compute net by filtering out rows.
• Multi-store. Omit storeId to aggregate across stores. If the merchant’s grant restricts your app to specific stores, the report is limited to those automatically.