Opens a new sale operation. This is a fiscal event — the platform records the start and, in jurisdictions that require it, signs it immediately.
The response includes fiscal.start_event with the start-side signature and
transaction counter. Store this — it must appear on the final receipt.
Multiple sales can be open simultaneously on the same register (restaurant tables, fuel pumps, workshop bays). Each gets its own fiscally-signed start.
Request:
{
"external_id": "table-3-order-42",
"cashier": { "id": "cashier_01", "display_name": "Maria R." }
}
Response:
{
"id": "op_01HXYZ",
"type": "sale",
"state": "open",
"started_at": "2026-02-25T19:02:11Z",
"fiscal": {
"regime": "tse",
"tse_serial": "abc123def456",
"client_id": "Kasse1",
"start_event": {
"signed_at": "2026-02-25T19:02:11Z",
"transaction_counter": 4821,
"signature": "base64encodedStartSignature=="
},
"end_event": null
}
}
Platform API key sent as Authorization: Bearer ofk_platform_....
Platform integrators also pass OpenFiskal-Organization: org_xxx
to act on behalf of a merchant.
Merchant organization ID. Required for platform integrators acting on behalf of a specific merchant. Omit when using an organization-scoped API key directly.
Unique key to make the request idempotent. If a request with this key
was already processed, the original response is returned without
re-executing the operation. Strongly recommended on all start and
complete actions — these are fiscal events and must not be duplicated.
Minimal data needed to open a sale. Line items and payments are added
via PATCH before completing. Only external_id and cashier are
required at start time — the fiscal event happens immediately.
Sale started and fiscally opened
Shared fields present on every operation regardless of type.
"op_01HXYZ"
"operation"sale The POS lifecycle state of the operation. Transitions are
one-directional and enforced server-side — invalid transitions
return 409 Conflict.
open — operation in progress, mutations allowedcompleted — POS finalized the operation (payment collected)cancelled — POS cancelled before completion| From | Event | To |
|---|---|---|
open | POST .../complete | completed |
open | POST .../cancel | cancelled |
open, completed, cancelled Monotonically increasing, register-scoped sequence number
Jurisdiction-specific fiscal output attached to every operation.
Discriminated by regime — each variant carries typed fields for its
fiscal security device and signing protocol.
The fiscalization state of the operation, tracked independently from the operation state.
pending — fiscalization not yet attempted or in progresssucceeded — fiscal device recorded the event, fiscal data availablefailed — fiscalization failed (device unreachable, transmission error)The POS should check fiscal.state before printing — only print
fiscal data on the receipt when it is succeeded.
pending, succeeded, failed Links to related operations. The audit chain between operations lives here
at the envelope level — not inside the type-specific data block — because
any operation type can reference any other.
Timestamp of the fiscal start event