Focus
Daily receipts transmission API: developer guide
The electronic transmission of receipts is now a mandatory step for all entities operating in retail and services. However, integration with the Revenue Agency's systems requires precision, reliability and careful management of operational cases. In addition, the identified solutions must not slow down business flows or represent an excessive cost. With this in mind, our APIs represent an effective tool to automate the process and integrate it into your systems. In this guide, we see how the API for sending receipts developed by us at A-Cube works. Throughout the paragraphs, we will see which API calls to make for each action.
New rules for sending receipts: modules and models
The transmission of receipts via API is regulated by the Revenue Agency. Indeed, solutions of this type are permitted as long as they comply with technical and control specifications and have obtained the necessary certifications. These are the so-called PEM and PEL modules, which work in an interconnected way to create a secure and unalterable data flow. In particular:
the PEM communicates with the merchant's cash register or electronic device. It acquires data for each transaction and creates a sealed “acquisition package” by applying a first electronic signature. In this way, it guarantees the integrity and authenticity of the data from the very first moment.
The PEL receives the sealed acquisition packages from the PEM, verifies the package signature and saves it in a protected and permanent registry that cannot be altered or deleted. It then aggregates the data for final transmission to the Revenue Agency.
The platform developed by A-Cube contains both modules. Depending on the role the partner intends to play, it is possible to opt for the mode:
partner as producer;
A-Cube as producer and partner as distributor;
A-Cube as producer and distributor.
These are three possible collaboration models aimed at producers, distributors and merchants. The A-Cube solution for receipts is designed to adapt to different levels of technological maturity and application complexity.
Integration of the API for sending receipts: how to start
How to integrate the A-Cube solution for receipts into existing systems? As a supplier, you need to register to create an account on the A-Cube platform and then authenticate as a supplier following the instructions in the Authentication section.
At this point, you need to create a new merchant account to register transactions, generate receipts for customers, and store and transmit fiscal data. To do this, you must use the following API endpoint:
POST https://ereceipts-it-sandbox.acubeapi.com/mf2/merchant
Content-Type: application/json
Accept: application/json
Authorization: Bearer <Supplier JWT Token>
{
"vat_number": "12345678901",
"address": {
"street_address": "street name",
"street_number": "xx",
"zip_code": "00000",
"city": "City",
"province": "XX"
},
"business_name": "business name",
"email": "merchant@example.com",
"password": "MerchantP4$$w0rd"
}
Response 201
{
"uuid": "123e4567-e89b-12d3-a456-426614174000",
"vat_number": "12345678901",
"fiscal_code": "XXXXXX00A00X000X",
"address": {
"street_address": "street name",
"street_number": "xx",
"zip_code": "00000",
"city": "City",
"province": "XX"
},
"business_name": "foo bar",
"first_name": "first name",
"last_name": "last name",
"email": "foobar@example.com"
}
At this point, it is possible to create a new PEM using the following API endpoint:
POST https://ereceipts-it-sandbox.acubeapi.com/mf2/pems
Content-Type: application/json
Accept: application/json
Authorization: Bearer <Supplier JWT Token>
{
"merchant_uuid": "836b70aa-239b-4c8d-b654-0f5a9a4d133a"
}
Response 201
{
"serial_number": "A2F4-000001",
"registration_key": "527462046048ce9bc72e64d77b975fdafd448825"
}
The physical address of the PEM is inherited from the address of the merchant created in the previous step. It will be needed to activate the PEM in the next step.
A-Cube API: PEM authentication and activation
At this point, with the previously created merchant profile, it is possible to log in and obtain a JWT token for merchants.
POST https://common-sandbox.api.acubeapi.com/login
Content-Type: application/json
Accept: application/json
{
"email": "merchant@example.com",
"password": "merchant password"
}
Response 200
{
"token": "Merchant JWT Token"
}
Now you can activate the PEM using the registration key obtained at the time of PEM creation. In that step, you receive the PEM serial number which is used in the API endpoint URL to identify the module.
POST https://ereceipts-it-sandbox.acubeapi.com/mf1/pems/A2F4-000001/activation/
Content-Type: application/json
Accept: application/json
Authorization: Bearer <Merchant JWT Token>
{
"registration_key": "527462046048ce9bc72e64d77b975fdafd448825"
}
Response 202
Now you can create a new cash register for the PEM. This must be authenticated with MF1 using an mTLScertificate (mutual TLS). To activate the license for the cash register and generate a new mTLScertificate through the API for sending receipts, you must make the following API call.
POST https://ereceipts-it-sandbox.acubeapi.com/mf1/cash-register
Content-Type: application/json
Accept: application/json
Authorization: Bearer <Merchant JWT Token>
{
"pem_serial_number": "A2F4-000001",
"name": "Cash register first floor"
}
Response 201
{
"uuid": "f69023bf-ee89-4d66-a7e7-9a65e4f365da",
"pem_serial_number": "A2F4-000001",
"name": "Cash register first floor",
"mtls_certificate": "----- BEGIN CERTIFICATE -----....",
"private_key": "-----BEGIN RSA PRIVATE KEY-----..."
}
This certificate is used to authenticate the cash register with the MF1 API and to identify it in the system. At this point, the content of the fields mtls_certificate and private_key can be stored in the memory of the cash register.
When saving the certificate and private key into files, the received values will contain the special character sequence "\n" representing line breaks. Before writing them to disk, make sure to replace each "\n" line break with a real line break. This ensures that the certificate and key are stored in the correct multiline format expected by the system.
Sending and retrieving receipts via A-Cube API
After following the previous steps, you can connect using the mTLScertificate to issue a receipt. The API client must be configured to use the previously generated mTLScertificate. All communications with MF1 using the mTLScertificate must be made on port 444 (i.e. https://ereceipts-it-sandbox.acubeapi.com:444).
In the section dedicated to developers, some examples are available on how to match a sending receipt of the mTLS certificate using different programming languages. Among these: Python, JavaScript, Bash and PHP.
The response received is the following:
Response 201
{
"uuid": "39f65b28-b1fa-401b-ad58-0addcaef7162",
"type": "sale",
"total_amount": "244",
"document_number": "0001-0001",
"document_datetime": "2025-07-22T09:45:22",
"parent_receipt_uuid": null,
"is_voidable": true,
"is_returnable": true,
"html_url": "url/to/html",
"pdf_url": "url/to/pdf"
}
At this point, it is possible to query the API for sending receipts to obtain the receipt data or get the PDF by sending the same request with the Accept header set to application/pdf.
To obtain the receipt data, you can use:
GET https://ereceipts-it-sandbox.acubeapi.com/mf1/receipts/39f65b28-b1fa-401b-ad58-0addcaef7162
Accept: application/json
Authorization: Bearer <Merchant JWT Token>
Response 200
{
"uuid": "39f65b28-b1fa-401b-ad58-0addcaef7162",
"type": "sale",
"total_amount": "244",
"document_number": "0001-0001",
"document_datetime": "2025-07-22T09:45:22",
"parent_receipt_uuid": null,
"is_voidable": true,
"is_returnable": true,
"html_url": "url/to/html",
"pdf_url": "url/to/pdf"
}
The PDF instead can be requested with:
GET https://ereceipts-it-sandbox.acubeapi.com/mf1/receipts/39f65b28-b1fa-401b-ad58-0addcaef7162/details
Accept: application/pdf
Authorization: Bearer <Merchant JWT Token>
Returning articles and cancelling a receipt via A-Cube API
In the section dedicated to developers adopting our API for transmitting receipts, you can see how to:
return items from a sales receipt issued by the same PEM you are using;
return items from a sales receipt issued by a different PEM;
return items from a sales receipt not issued by a PEM.
In all three cases, the receipts must have been issued by a merchant or cashier in possession of a valid certificate (PEM file).
The examples in the guide are available in Python, JavaScript, Bash and PHP.
Via the A-Cube API it is also possible to cancel a sales receipt. As with the return of items, in the appropriate section of the guide there are references in different languages. The cases that occur - and for which specific examples are present - are:
how to cancel a sales receipt issued by the same PEM you are operating from;
how to cancel a sales receipt issued by a different PEM;
how to cancel a sales receipt not issued by a PEM.
Sending receipts via API: efficiency and control with A-Cube
Integrating an API for transmitting receipts into your business flows is not just about complying with a regulatory obligation, but building a solid, scalable infrastructure ready to evolve alongside the business. To do so, however, you must identify the most suitable solution. The difference is made by the ability to seamlessly manage every stage of the process, from the activation of the PEM and PEL modules to the management of returns and cancellations. All of this without introducing superfluous complexity. The APIs developed by us at A-Cube are designed with precisely this goal in mind: to offer developers clear, documented tools consistent with the specifications of the Revenue Agency. Want to find out more? Write to info@acubeapi.com and discover how our API-first solutions can make a difference for your business.
