Status values in receipts, devices and webhooks

When you read an API response, receive a webhook or look at a Portal screen, you'll see status fields with a small set of fixed values. This page lists every value you can encounter, what it means in business terms, and when e-bon sets it.

Track receipt command status

When you send a receipt or any other fiscal command to a device, e-bon assigns a status to the command and updates it as the device picks it up and responds.

Typical lifecycle:

   POST /api/v1/devices/:deviceId/commands
                  │
                  ▼
           ┌──────────┐
           │ pending  │
           └────┬─────┘
                │ delivery starts
                ▼
           ┌──────────┐    device confirms success     ┌────────────┐
           │   sent   │ ─────────────────────────────▶ │ completed  │ (final)
           └────┬─────┘                                └────────────┘
                │ device returns an error
                ▼
           ┌──────────┐
           │  failed  │ (final)
           └──────────┘

   The wakeup wait expires (60 s) or the safety sweeper picks up
   a command stuck in pending/sent for more than 180 s:
                       ┌──────────┐
                       │ timeout  │ (final)
                       └──────────┘

Once a command reaches completed, failed or timeout, e-bon will not change it again.

Where you see it:

• API responses for GET /api/v1/commands/:id and GET /api/v1/devices/:deviceId/commands/:id, on the status field.
• Webhook payloads command.completed, command.failed and command.timeout — see Webhook events.
• Portal Devices → Activity column.

For the full delivery flow (live connection plus push fallback), see Receipt emission flow. For the catalogue of command types, see Command types.

Read device connectivity status

Each AMEF device registered in e-bon carries a connectivity status that reflects whether the cloud can reach it right now.

The device flips between online and offline for the entire life of its registration; there is no final state.

Where you see it:

• API responses for GET /api/v1/devices and GET /api/v1/devices/:id, on the status field.
• Webhook payloads device.online and device.offline.
• Portal device card status badge (red/grey).

Read webhook delivery status

Every webhook event e-bon sends to your endpoint creates a delivery record with its own status. You can inspect deliveries to debug your integration.

Lifecycle:

   dispatch
     │
     ▼
  ┌──────────┐  attempt 1 succeeds (2xx)   ┌──────────┐
  │ pending  │ ──────────────────────────▶ │ success  │ (final)
  └────┬─────┘                             └──────────┘
       │ attempt fails
       ▼
  ┌──────────┐  later attempt succeeds     ┌──────────┐
  │ pending  │ ──────────────────────────▶ │ success  │ (final)
  │ retrying │
  └────┬─────┘
       │ attempt 5 still fails
       ▼
  ┌──────────┐
  │  failed  │ (final)
  └──────────┘

After a non-2xx response the delivery stays pending and is retried on the schedule [60 s, 5 min, 30 min, 2 h, 12 h]. A maximum of 5 attempts is made. If a webhook accumulates 20 consecutive failed deliveries, it is auto-disabled and an admin must re-enable it from the Portal.

Where you see it:

• API response for GET /api/v1/webhooks/:id/deliveries, on the status field.
• Portal Settings → Webhooks → deliveries panel.
• The parent webhook also exposes lastDeliveryStatus (success or failed), updated on each final outcome.

For the retry contract, the auto-disable rule and how the response body is captured, see Webhook events.

Read device alert severity

When a device is in a state that needs attention (paper running low, cover open, Z report overdue, etc.), e-bon attaches a severity to each alert it surfaces.

Alerts are computed at read time from the device's current state — they are not stored. When a device has multiple alerts, the highest severity wins the badge color in the Portal (errors trump warnings).

Where you see it:

• API responses for GET /api/v1/devices/alerts and GET /api/v1/devices/:id/alerts, on the severity field of each alert.
• Portal device card badge color.

For the rules and thresholds behind each alert type, see Portal alerts.

Track ANAF report status

Electronic Journal (Jurnal Electronic, JE) reports carry an ANAF acceptance status that reflects what happened after the operator submitted the file to ANAF SPV.

   JE generated (status absent or 'pending')
                 │
                 ▼
       ┌──────────────────┐
       │     pending      │
       └────────┬─────────┘
                │ operator submits to SPV, then PATCHes the report:
                ├────────────▶ ┌──────────┐
                │              │ accepted │
                │              └──────────┘
                ├────────────▶ ┌──────────┐
                │              │ rejected │
                │              └──────────┘
                └────────────▶ ┌──────────┐
                               │  error   │
                               └──────────┘

Where you see it:

• API responses for GET /api/v1/reports/je and GET /api/v1/reports/je/:id, on the anafStatus field.
• Portal Reports → ANAF status column.

For the SPV submission process and the legal background, see ANAF reporting.

Identify receipt types

Each receipt carries a type that indicates its legal nature. The type is set when the receipt is emitted and never changes afterwards.

Where you see it:

• API responses for receipt resources, on the Receipt.type field.
• Portal Receipts → Type column.

Identify user roles

Each user belongs to an organization with one of three roles. Role changes are applied directly by an admin or owner — there is no transition workflow.

Where you see it:

• The role appears as a claim on every authenticated request and in the User.role field on member-listing and current-user endpoints.
• Portal Settings → Organization → Members column.

For how each role gates the API and the full RBAC matrix, see Authentication and authorization.

Identify subscription plans

Each organization is on one of three subscription tiers. The plan controls device caps, API throughput and access to paid features.

Where you see it:

• API responses, on the Organization.plan field.
• Portal Settings → Subscription.

Tier-enforcement is applied on every API request to gate paid features — see Authentication and authorization.

Where to next

• Commands API — request envelope and polling contract for receipt commands.
• Webhook events — full payload list, including command.completed, command.failed, command.timeout, device.online and device.offline.
• Portal — Devices — where device status and alert severities surface in the UI.
• Portal — Alerts — derivation rules behind each alert.
• Receipt emission flow — full command lifecycle including the live-connection / push-wakeup fallback.
• Webhook events — full delivery lifecycle and retry contract.
• Authentication and authorization — role gates and plan-tier enforcement.
• ANAF reporting — operator-driven ANAF status workflow.
• Glossary — Romanian fiscal vocabulary referenced here (storno, AMEF, raport Z, etc.).
• Command types — per-type catalogue that uses the command status lifecycle.