Cloud EFR

Cloud EFR is a fully efsta-managed fiscalisation service where EFR runs in efsta's cloud infrastructure. There is no software to install or maintain on your side — efsta handles all configuration, updates, scaling, and operations.

info

Product only available on request. To get access, contact your efsta partner manager or write to ticket@efsta.eu.

What is Cloud EFR?

EFR hosted and operated entirely by efsta
Accessible via HTTPS API using OAuth Bearer token authentication
Same transaction request format as a locally installed EFR
No local web UI at localhost:5618
No fiscal hardware (printers, hardware signature devices) required or supported
efsta handles the initial connection of the EFR to the company or organisation via badge; all other settings must be configured by the customer either through the API or the efsta Portal

When to use it

warning

Cloud EFR is exclusively for POS systems that are fully cloud-based and have no offline capability. If your POS system needs to work without an internet connection, use Local EFR (Getting Started) instead.

Ordering

Cloud EFRs are created by efsta. To order one:

Contact your efsta partner manager, or email ticket@efsta.eu
efsta creates the Cloud EFR and provides your API Key and API Secret
You can find them in your company's properties in the efsta Portal

Authentication

Cloud EFR uses OAuth 2.0 client credentials. Implement the following flow in your cloud POS:

Authorize with ApiKey and ApiSecret to get access token and refresh token.
Access- and refresh tokens should be temporarily stored on the cloud POS system.
With the access token, requests can be sent to the cloud EFR.
If the access token has expired (HTTP 401 { "error": "invalid_token", "error_description": "Invalid token: access token is invalid" }), the cloud POS can use its refresh token to request new access- and refresh tokens, which are temporarily saved once more. You can also check before each request whether the token has already expired.
If the refresh token has expired as well (same HTTP 401 response), access- and refresh tokens must be re-requested with ApiKey and ApiSecret.

info

Token Validity
- Access token: 1 hour
- Refresh token: 7 days
- These expiry dates may still be up to change.

Getting tokens

Access tokens are scoped to the TaxId, TL, and TT used during issuance.

Method 1: HTTP Basic Auth
Method 2: Credentials in Body
Multi-Company

POST /auth/token

[Headers]
Authorization: Basic base64(ApiKey:ApiSecret)
Content-Type: application/x-www-form-urlencoded

[Body]
grant_type=client_credentials
TaxId=...
TL=...
TT=...

POST /auth/token

[Headers]
Content-Type: application/x-www-form-urlencoded

[Body]
grant_type=client_credentials
client_id=ApiKey
client_secret=ApiSecret
TaxId=...
TL=...
TT=...

Refreshing tokens

Refresh tokens are scoped to the same TaxId, TL, and TT as the access tokens issued with them.

POST /auth/token

[Headers]
Content-Type: application/x-www-form-urlencoded

[Body]
client_id=ApiKey
grant_type=refresh_token
refresh_token=tGz...
TaxId=...
TL=...
TT=...

Token response format

The response format is identical whether you're requesting tokens via Basic Auth, body credentials, or using a refresh token.

{
  "access_token": "eyJ0...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "eyJ0...",
  "access_token_expires": 1753865826,
  "access_token_expires_at": 1753865826,
  "refresh_token_expires": 1755071826,
  "refresh_token_expires_at": 1755071826,
  "api_key": "1124_Test..."
}

Field	Type	Description
`access_token`	`string`	Bearer token used for authenticating API requests.
`token_type`	`string`	Token type (always `"Bearer"`).
`expires_in`	`number`	Time in seconds until the access token expires.
`refresh_token`	`string`	Token that can be used to obtain a new access token.
`access_token_expires`	`number`	Expiry timestamp of the access token (Unix time).
`access_token_expires_at`	`number`	Same as above, included for compatibility.
`refresh_token_expires`	`number`	Expiry timestamp of the refresh token.
`refresh_token_expires_at`	`number`	Same as above.
`api_key`	`string`	Echo of the `ApiKey` used.

Making requests

Send all EFR requests with the access token in the Authorization header.

Request Header:

Name	Value
`Authorization`	`Bearer [ACCESS_TOKEN]`

The request body is identical to a locally installed EFR. See the API reference for full documentation.

Example: /state endpoint

API Reference: EFR State

GET /state

[Headers]
Authorization: Bearer [ACCESS_TOKEN]

Example: /register endpoint

API Reference: Cashier Log In

POST /register

[Headers]
Authorization: Bearer [ACCESS_TOKEN]

[Body]
{
  "Tra": {
    "ESR": {
      "D": "2024-06-01T08:30:15",
      "TaxId": "DE123456789"
      "TL": "001",
      "TT": "1",
      "TN": "35",
      "NFS": "LOGIN",
      "Opr": "101",
      "OprN": "Mario Rossi",
      "OprTIN": "xxx"
    }
  }
}

Capacity & modes

For more than 100 POS installations, your partner manager can create additional Cloud EFRs
- These share the same API credentials
- POS installations are distributed evenly
MultiCompany mode requires setup consultation with a partner manager
- Digital receipt management is not available in MultiCompany mode

Mode	POS limit per EFR	Use case
MultiPOS (default)	Up to 100	One company, multiple cloud POS instances
MultiCompany	Up to 100	One EFR handles multiple companies and locations

Exports

Fiscalised data can be accessed two ways:

efsta Portal — download audit files, journals, and reports from the Portal UI
HTTP requests — send authenticated requests to the Cloud EFR endpoint using the same /export endpoints as local EFR

Country-specific guides

Steps 1 (API integration) and 2 (Portal setup) of each country's Quick Start apply unchanged. Country-specific fiscal steps apply where they do not require hardware devices.

Continue with your country guide after completing setup above: