Integration Guide: eReporting

1. Authentication

Authenticate with your Service Account and send the returned access_token as Authorization: Bearer <access_token> on every call. These endpoints require that Bearer token, because the token is what identifies you to the reporting platform. An X-API-Key credential is not accepted on them: sending the X-API-Key header is refused even when an Authorization header accompanies it, so a client migrated to API keys must call these four routes with the Bearer token only. The scheme itself is case-insensitive.

A Brand, Brand Group or Restaurant account may read these reports, each within its own perimeter. Any other identity, such as a POS or kiosk device token or a customer token, is refused with a 401 permission_denied before the reporting platform is called.

{
  "username": "service.account@brand.com",
  "password": "YOUR_SECURE_PASSWORD",
  "grant_type": "password"
}

{
  "access_token": "eyJhbGciOiJIUzI1...",
  "status": 201,
  "code": "token_created",
  "message": "You have successfully logged in.",
  "data": {
    "user": {
      "userId": 1,
      "email": "service.account@brand.com",
      "role": "brand",
      "brandId": 100
    }
  },
  "token_type": "Bearer"
}

2. Daily Report

Aggregated sales and payments for one restaurant and one business date. orders[] holds one entry per fiscal category present that day (GOODS_VAT for supply of goods, SERVICES_VAT for provision of services), each with its VAT breakdown; payments[] holds one entry per payment method and VAT rate, the VAT being allocated pro-rata across each order's payments. A day without activity returns a valid payload with empty arrays, never a 404.

{
  "date": "2026-09-03",
  "restaurantId": "123",
  "reconciled": true,
  "orders": [
    {
      "category": "SERVICES_VAT",
      "currency": "EUR",
      "total": 1234.5,
      "taxAmount": 112.23,
      "totalOrders": 87,
      "taxDueDateTypeCode": "432",
      "taxes": [
        {
          "taxRate": 10,
          "taxAmount": 112.23,
          "totalExclTax": 1122.27,
          "totalInclTax": 1234.5
        }
      ]
    }
  ],
  "payments": [
    {
      "paymentMethodId": "CreditCard",
      "paymentMethodName": "Carte bancaire",
      "currency": "EUR",
      "taxRate": 10,
      "taxAmount": 80.5,
      "total": 885.5
    }
  ]
}

3. Closures

Cash-register closures ("clôtures" / Z) for one restaurant and one business date. Several closures per date are possible (one per work slot, or one per day). status becomes closed once the business date is frozen, at the latest at 04:00 local time the following day. A closure's figures are frozen at closing time; a re-issued closure keeps the same id with a new version.

{
  "date": "2026-09-03",
  "status": "closed",
  "closures": [
    {
      "id": "pec_abc123",
      "total": 1360.03,
      "taxAmount": 123.64,
      "payments": [
        {
          "paymentMethodId": "Cash",
          "paymentMethodName": "Espèces",
          "tip": 0,
          "total": 240
        }
      ],
      "taxes": [
        {
          "taxRate": 10,
          "taxAmount": 123.64,
          "total": 1360.03
        }
      ]
    }
  ]
}

4. Orders of a Closure

The individual orders belonging to a closure, paginated with an opaque cursor. Keep calling with the nextCursor of the previous page until it comes back null. The orders are resolved from the closureId itself; restaurantId does not filter the page and is required only to authorize the request. It must still designate a restaurant that exists: an unknown one is refused with 400 restaurant_not_found before the reporting platform is called.

This route is the one exception to the perimeter check described above: because a closure is not selected by restaurantId, it is the reporting platform, and not this API, that decides whether the closure is yours to read. A closure outside your perimeter therefore comes back as io_data_platform_request_rejected carrying the platform's own status (403for a scope you do not hold, 404 for a closure that does not exist) rather than as permission_denied. For the same reason the deactivated-restaurant limitation of the daily report does not apply here: nothing on this route refuses a closed site locally.

{
  "closureId": "pec_abc123",
  "orders": [
    {
      "orderId": "ord_78910",
      "timestamp": "2026-09-03T12:41:05+02:00",
      "currency": "EUR",
      "totalInclTax": 15.6,
      "taxAmount": 1.42
    }
  ],
  "nextCursor": null
}

5. File Export over a Period

The same figures as the daily report, for every business date of a range, delivered as a file rather than as JSON in the body: format=json returns one array of daily payloads, format=csv returns a ZIP of two CSVs (transactions and payments).

The bounds of the range are not checked by this API: neither its width nor startDateactually preceding endDate is validated here. Both rules belong to the reporting platform, which caps a range at 92 days, so a range it refuses comes back as io_data_platform_request_rejected carrying the platform's own 400, and not as invalid_parameters, which on this route only ever signals a missing, misshapen or unknown parameter.

Binary file. Content-Disposition carries the filename, X-Checksum-Sha256 the SHA-256 of the body.

Compute the SHA-256 of the bytes you received and compare it with X-Checksum-Sha256 to prove the file was not truncated in transit. Both headers are CORS-exposed.

A wide range is aggregated day by day and can legitimately take minutes: set your own client timeout to at least three minutes. The reporting platform is given 120 seconds to answer, past which the request ends on a 502 io_data_platform_unreachable rather than on a truncated file, and the API holds the connection open for at most 150 seconds in total; a call still silent by then is over, so retry it rather than wait. Both budgets apply to the three JSON routes as well.