Error

A valid request URL is required to generate request examples

{
  "sellerId": "user-camille",
  "day": "2026-07-16",
  "storeId": "store-rivoli",
  "salesCount": 1,
  "returnsCount": 0,
  "revenueCents": 3600,
  "itemsSold": 2,
  "basketAverageCents": 3600,
  "vatTotalCents": 600
}

{
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "<string>",
    "statusCode": 123,
    "fieldErrors": [
      {
        "field": "<string>",
        "message": "<string>"
      }
    ]
  }
}

{
  "error": {
    "message": "<string>",
    "statusCode": 123
  }
}

{
  "error": {
    "message": "<string>",
    "statusCode": 123
  }
}

Auth

Tally the authenticated actor's own day

Rolls the CALLER’s own finalized sale tickets for ONE UTC calendar day up into their day figures: sales and returns counts, net gross TTC taken (chiffre d’affaires), items sold, basket average and VAT. Optionally pass ?day=YYYY-MM-DD (defaults to today) and ?store= to narrow to one store. Money is integer cents.

WHOSE FIGURES. The caller’s, and there is no parameter that can change that: the seller is the authenticated actor id, so this operation needs no scope and can never report on a colleague. To read somebody ELSE’s day, call GET /v1/sales/seller-day, which rides pos.finance.view. Sales are attributed by SaleTicket.sellerId, a GET /v1/team member id (user-*), so an actor whose id names no directory member — a machine principal or one of the local-dev app subjects — has rung nothing and reads back a day of zeros. Call GET /v1/auth/whoami first: a null identity there means this operation is answering for an account that is nobody, and its zeros describe no employee.

WHICH DAY. The window is the UTC calendar day of recordedAt, the instant the BACKEND booked each sale — the same bucket the daily Z closure, the FEC and the accounting export use, so an employee’s figure agrees with their store’s close. It is deliberately NOT the instant the till rang the sale up: the two diverge by days for a sale captured offline and replayed later.

READING ZEROS. A day with no ticket is a successful read returning zeros — a real, quiet day. It is NOT what a failed read looks like, and a client must never render a transport failure as 0: on this surface the two are indistinguishable to the person reading them, and the zero is the one that gets believed.

GET

day-summary

Error

A valid request URL is required to generate request examples

{
  "sellerId": "user-camille",
  "day": "2026-07-16",
  "storeId": "store-rivoli",
  "salesCount": 1,
  "returnsCount": 0,
  "revenueCents": 3600,
  "itemsSold": 2,
  "basketAverageCents": 3600,
  "vatTotalCents": 600
}

{
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "<string>",
    "statusCode": 123,
    "fieldErrors": [
      {
        "field": "<string>",
        "message": "<string>"
      }
    ]
  }
}

{
  "error": {
    "message": "<string>",
    "statusCode": 123
  }
}

{
  "error": {
    "message": "<string>",
    "statusCode": 123
  }
}

Authorizations

Authorization

string

header

required

Authorization: Bearer <token>. Accepts EITHER a Keycloak access token (scopes-in-token) OR an opaque POS session token; both resolve to the same pos.* scope vocabulary the route guards enforce.

Query Parameters

day

string

The UTC calendar day (YYYY-MM-DD) to tally; defaults to today. A malformed day 400s.

store

string

Narrow the tally to one store by its canonical store id; omit to span every store.

Response

The caller's own tallies for the requested UTC calendar day.

sellerId

string

required

day

string

required

The UTC calendar day tallied (YYYY-MM-DD).

storeId

string | null

required

The store the window was narrowed to, or null.

salesCount

integer

required