> ## Documentation Index > Fetch the complete documentation index at: https://docs-pos.solya.app/llms.txt > Use this file to discover all available pages before exploring further. # 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. ## OpenAPI ````yaml /openapi.json get /v1/me/day-summary openapi: 3.0.3 info: title: Solya POS API version: 1.0.0 description: >- The Solya POS backend HTTP surface. Every documented operation is agent-ready: it carries an `operationId`, an agent-facing `description`, the `pos.*` scopes it enforces (`x-required-permissions`) and an `x-agent-tier`. Success responses return the payload as raw JSON; failures return the `ErrorResponse` envelope (`{ error: { code, message, statusCode } }`). servers: - url: / description: The backend, relative to its deployed origin. security: [] paths: /v1/me/day-summary: get: tags: - Auth summary: Tally the authenticated actor's own day description: >- 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. operationId: myDaySummary parameters: - schema: type: string in: query name: day required: false description: >- The UTC calendar day (`YYYY-MM-DD`) to tally; defaults to today. A malformed day 400s. - schema: type: string in: query name: store required: false description: >- Narrow the tally to one store by its canonical store id; omit to span every store. responses: '200': description: The caller's own tallies for the requested UTC calendar day. content: application/json: schema: type: object properties: sellerId: type: string day: type: string description: The UTC calendar day tallied (`YYYY-MM-DD`). storeId: nullable: true description: The store the window was narrowed to, or `null`. type: string salesCount: type: integer minimum: -9007199254740991 maximum: 9007199254740991 returnsCount: type: integer minimum: -9007199254740991 maximum: 9007199254740991 revenueCents: type: integer minimum: -9007199254740991 maximum: 9007199254740991 description: Net gross TTC taken, integer cents (refunds negative). itemsSold: type: integer minimum: -9007199254740991 maximum: 9007199254740991 basketAverageCents: type: integer minimum: -9007199254740991 maximum: 9007199254740991 vatTotalCents: type: integer minimum: -9007199254740991 maximum: 9007199254740991 required: - sellerId - day - storeId - salesCount - returnsCount - revenueCents - itemsSold - basketAverageCents - vatTotalCents additionalProperties: false description: The caller's own tallies for the requested UTC calendar day. example: sellerId: user-camille day: '2026-07-16' storeId: store-rivoli salesCount: 1 returnsCount: 0 revenueCents: 3600 itemsSold: 2 basketAverageCents: 3600 vatTotalCents: 600 '400': description: >- The request failed schema validation; `error.fieldErrors` lists the fields. content: application/json: schema: $ref: '#/components/schemas/ValidationErrorResponse' '401': description: No valid credential was presented — send a bearer token. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '500': description: An unexpected server error — safe to retry idempotent requests. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - bearerAuth: [] components: schemas: ValidationErrorResponse: type: object required: - error additionalProperties: false description: >- A `VALIDATION_FAILED` envelope carrying the offending fields in `fieldErrors`. properties: error: type: object required: - code - message - statusCode additionalProperties: false properties: code: type: string enum: - VALIDATION_FAILED message: type: string statusCode: type: integer fieldErrors: type: array description: >- One entry per rejected field: the field path and why it was rejected. items: type: object required: - field - message additionalProperties: false properties: field: type: string description: Dot-path of the offending field. message: type: string description: Why the field was rejected. ErrorResponse: type: object required: - error additionalProperties: false description: The uniform failure envelope every non-2xx response returns. properties: error: type: object required: - code - message - statusCode additionalProperties: false properties: code: type: string enum: - VALIDATION_FAILED - UNAUTHORIZED - FORBIDDEN - NOT_FOUND - CONFLICT - BUSINESS_RULE_VIOLATION - INTERNAL_ERROR description: >- Machine-readable kernel `ResultCode` — branch on this, not on `message`. message: type: string description: >- Human-readable explanation. Safe to surface; never leaks server internals. statusCode: type: integer description: >- The HTTP status, mirrored into the body so a client need not read headers. securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: JWT description: >- `Authorization: Bearer `. 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. ````