Reports
Reports
The Reports API reads reports live from the fiscal device. There is no stored report model: the AMEF's fiscal memory (MF) and electronic journal (JE) are the legal record, so every endpoint below dispatches a command to the device through its controller and returns the device's answer synchronously. All routes live under /api/v1/devices/{deviceId}/reports.
Every endpoint requires the reports scope and accepts either an API key (x-api-key / Authorization: Bearer …) or a Portal JWT. See Authentication › Choose scopes.
503 with a connectivity error code (E600/E601/E602) — see Errors.Capability discovery
GET /api/v1/devices/{deviceId}/reports/capabilities
Reads which report operations the device's driver supports. Gate your UI on these flags — not every AMEF supports every operation.
Response (200 OK)
{
"capabilities": {
"canReadMfStructured": true,
"canReadEjStructured": true,
"canExportANAFByDate": true,
"canExportANAFByZRange": false,
"supportsAnafStorageRamDisk": true,
"supportsAnafStorageSdCard": false,
"supportsPeriodicByDate": true,
"supportsPeriodicByZNumber": true
},
"deviceId": "dev_pos_01",
"timestamp": "2026-07-13T10:00:00.000Z"
}
GET /api/v1/devices/{deviceId}/reports/telemetry
Reads fiscal-memory and electronic-journal counter telemetry (usage, capacity, near-full flags).
Response (200 OK)
{
"mfInfo": {
"fiscalizationDate": "2025-01-10T00:00:00",
"lastClosedZ": 412,
"zUsed": 412,
"zCapacity": 2500,
"nearFull": false,
"full": false
},
"ejInfo": {
"counterUnit": "lines",
"used": 182400,
"remaining": 817600,
"capacity": 1000000,
"nearFull": false,
"full": false
},
"deviceId": "dev_pos_01",
"timestamp": "2026-07-13T10:00:00.000Z"
}
mfInfo.fiscalizationDate is null while the device is not fiscalized (there is no fiscalization date yet) or when the firmware cannot report it.
ejInfo is only as numeric as the device protocol allows. counterUnit tells you what used counts: 'lines' (Custom: the journal is a line buffer, so remaining/capacity are real numbers), 'documents' (Datecs: the journal is a document store, used is the global document counter and remaining/capacity are null because the firmware reports no numeric journal capacity), or 'none' (Tremol: no usage counter on the wire, used stays 0). On every protocol the truthful fullness signals are the nearFull/full flags.
Range selection
The MF/EJ reads and the periodic print accept either a calendar date range or a Z-closure number range (both inclusive):
| Parameter | Type | Notes |
|---|---|---|
fromDate | string | YYYY-MM-DD, pair with toDate. |
toDate | string | YYYY-MM-DD, pair with fromDate. |
fromZ | integer | >= 1, pair with toZ. |
toZ | integer | >= fromZ, pair with fromZ. |
Fiscal memory (Z history)
GET /api/v1/devices/{deviceId}/reports/mf
Reads Z-closure rows from the device's fiscal memory for the given range. This is the source of Z history — a Z report is a destructive day-end operation, never a query; its historical record lives in fiscal memory.
curl "https://api.e-bon.ro/api/v1/devices/dev_pos_01/reports/mf?fromDate=2026-06-01&toDate=2026-06-30" \
-H "x-api-key: $EBON_API_KEY"
Response (200 OK)
{
"mf": {
"entries": [
{ "date": "2026-06-01T20:01:12", "zNumber": 401, "grossTotalCents": 1284500 }
],
"fromDate": "2026-06-01T00:00:00",
"toDate": "2026-06-30T23:59:59",
"fromZ": 401,
"toZ": 430
},
"deviceId": "dev_pos_01",
"timestamp": "2026-07-13T10:00:00.000Z"
}
Electronic journal
GET /api/v1/devices/{deviceId}/reports/ej
Reads the electronic journal's verbatim text blocks, one block per Z closure in the range.
Response (200 OK)
{
"ej": {
"blocks": [
{ "zNumber": 401, "lines": ["BON FISCAL", "1 x Espresso 9.00", "TOTAL 9.00"] }
],
"fromDate": "2026-06-01T00:00:00",
"toDate": "2026-06-01T23:59:59",
"fromZ": 401,
"toZ": 401,
"totalLines": 3
},
"deviceId": "dev_pos_01",
"timestamp": "2026-07-13T10:00:00.000Z"
}
Report prints
POST /api/v1/devices/{deviceId}/reports/x
Produces an X report (daily running totals, non-destructive) on the device's printer. Returns the device-reported summary; structured totals depend on driver support.
Response (200 OK)
{
"report": {
"reportType": "x",
"deviceId": "dev_pos_01",
"totals": { "sales": 0, "refunds": 0, "net": 0 },
"vatBreakdown": [],
"receiptCount": 0,
"timestamp": "2026-07-13T10:00:00.000Z"
},
"deviceId": "dev_pos_01",
"timestamp": "2026-07-13T10:00:01.000Z"
}
POST /api/v1/devices/{deviceId}/reports/z
Runs a Z report (end-of-day closure) on the device. Destructive: resets daily counters and advances fiscal memory. Same response shape as the X print. A device that requires a Z before further sales reports E303 on other operations — see Errors.
POST /api/v1/devices/{deviceId}/reports/periodic
Prints a periodic fiscal-memory report on the device's paper for the given range (JSON body, see Range selection).
curl -X POST "https://api.e-bon.ro/api/v1/devices/dev_pos_01/reports/periodic" \
-H "x-api-key: $EBON_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "fromDate": "2026-06-01", "toDate": "2026-06-30" }'
Response (200 OK)
{ "success": true, "deviceId": "dev_pos_01", "timestamp": "2026-07-13T10:00:00.000Z" }
ANAF archive export
POST /api/v1/devices/{deviceId}/reports/anaf-export
Exports the device's ANAF monthly archive (the signed ZIP the AMEF produces for the tax authority) for the given range. Body accepts the range fields plus an optional storageTarget ("ramdisk" or "sdcard") on devices that advertise both storage options.
The device builds the archive asynchronously — slow months legitimately take minutes. The request waits for the whole build + transfer; the optional timeoutMs body field sets the device-side deadline (whole export, clamped to 30 s – 30 min, default 10 min) and the gateway outwaits it. Prefer raising timeoutMs over aborting and retrying: the printer keeps building either way, and a retry rebuilds from scratch.
The archive is returned base64-encoded; decode it and save as a .zip.
curl -X POST "https://api.e-bon.ro/api/v1/devices/dev_pos_01/reports/anaf-export" \
-H "x-api-key: $EBON_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "fromDate": "2026-06-01", "toDate": "2026-06-30" }'
Response (200 OK)
{
"export": {
"filename": "pkcs7export.zip",
"base64": "UEsDBBQAAAAI…",
"sizeBytes": 482133
},
"deviceId": "dev_pos_01",
"timestamp": "2026-07-13T10:00:00.000Z"
}
Error codes
| Status | Code | Meaning |
|---|---|---|
400 | VALIDATION_ERROR | Missing/invalid range or body. |
404 | NOT_FOUND | Device does not exist in the organization. |
422 | E2xx/E3xx | The device refused the operation (e.g. E303 Z required). |
503 | E600/E601/E602 | No controller assigned / controller offline / transport down. |
500 | INTERNAL_ERROR | The device answered without the expected payload. |
Receipts
REST endpoints for storing, listing and retrieving fiscal receipts after they have been printed on the AMEF — request and response schemas, curl examples and per-endpoint error codes.
Devices
REST endpoints for managing fiscal devices (AMEFs) — CRUD, release, live status, alerts, and the full set of device commands (cash balance, datetime, logos, VAT rates, header/footer, operators, void, reversal, etc.).