Skip to content

Features

This page lists the primary features of the Invoicetronic API.

Don't forget to check our Roadmap.

Encryption at rest

Encryption at rest is a security measure that encrypts stored data when it is not actively used (i.e., not being read or modified). It ensures the data is protected from unauthorized access, even if the underlying storage system is compromised.

The Invoicetronic API complies with industry standards and regulations for data protection by encrypting invoices and other sensitive data at rest, using modern encryption algorithms such as AES-256. Only the owner (you) can retrieve the original content when accessing it through a secure connection and authenticated API requests.

OpenAPI specification

By providing you with a fully compliant OpenAPI specification, we ensure you have everything you need to seamlessly integrate with our API, reduce development time, and focus on creating value for your users. To learn more about the Invoicetronic OpenAPI specificartion and its advantages, see the OpenAPI section.

Pre-flight, multi-language, invoice validation

You can validate your invoices before sending them to the FatturaPA/SDI. Pre-flight validation applies the same strict rules applied by the SDI. The API replies with a 422 Unprocessable Entity response and a list of errors if the submitted document does not pass validation.

Validation can be applied in two ways:

After successful validation, the latter will store the document and send it to SDI. If you don't validate outgoing documents, they will be sent to the SDI as they are and will eventually be rejected by the SDI if they are invalid (you will be informed via a status update).

By default, validation errors are in Italian. You can use the Invoicetronic-Language header to request errors in other languages. For example, a request with the Invoicetronic-Language: en will ensure that any validation error is returned in English. Currently supported languages are Italian, English, German. Your language is missing? Open a ticket or contribute it yourself.

Pre-flight validation is helpful in scenarios where invoice conformity is uncertain. One such use case is when a user has a draft and wishes to know if it is ready for submission. Sending a non-conforming document to the SDI is sub-optimal because he/she will know it has been rejected only at a later time via a status update.

SDI error codes 3xx

Remember that some validations, such as a formally correct but nonexistent VAT Number, are outside the API's scope. In general, prior validation cannot detect SDI code 3xx errors. Thus, in rare cases, SDI will still reject an invoice validated by the API.

Digital signatures (P7M)

On the Invoicetronic API, you can store both digitally signed and unsigned invoices. The API can optionally apply a digital signature to an uploaded invoice, sparing you the process of signing it locally before the upload (which can be complex and costly.)

By default, the API will automatically sign unsigned invoices for Public Authority offices, as a signature is mandatory for them. At the same time, documents for private businesses are untouched unless you explicitly request the API to sign them. You can opt out of this behaviour at any time, as you can activate or deactivate the signature feature on each individual upload.

Multiple upload formats

The Invoicetronic API collects your outbound invoices and forwards them to the SDI, for delivery to the designated recipients. When uploading invoices, you have multiple options to choose from. Pick the one that better fits your use case.

  • Standard. This method offers more control as you can provide details. The request Content-Type header is application/json, and its body is a JSON object with properties such as. file_name, meta_data, and payload, which holds the actual invoice xml content, either as a Base64-encoded (recommended) or a plain string.
  • File. When you have an invoice file ready, you can directly upload it. The filename will be picked up, and its content can be either Base-64 encoded or in plain text. Our invoice command line tool uses this method to quickly send and receive single or bulk invoice files from the command line.
  • XML. This method lets you leverage the application/xml Content-Type header to send the invoice content as xml string. An unique, rule-compliant filename will be generated and automatically assigned to the document.
  • JSON. Allows your integration to upload a JSON invoice via the application/json Content-Type header. A unique, compliant filename will be generated and automatically assigned to the document. This option is handy to generate compliant XML content from your integration.

All methods support optional pre-flight validaiton and digital signatures. For more information with the upload endpoints at the API reference.

Status updates

Once the API forwards an invoice, the SDI will try to dispatch it to the recipient. Your integration can query the API anytime to learn about any document's delivery state; there's a dedicated endpoint just for that. Examples of possible status updates are:

Status Description
Inviato Sento to the SDI
Consegnato Delivered to the recipient
Scartato Rejected by the SDI, likely because of a validation issue
ImpossibilitaDiRecapito Available on the recipient's tax drawer, but it was impossibile to deliver it to the recipient's reception system

For more information see updates endpoint page on the API reference.

Tip

Besides the pull mechanism described above, where your application routinely checks the API for updates, you can also opt for a push workflow. See Webhooks below for more information.

Incoming invoices

Incoming invoices are available at the dedicated receive API endpoint. There, your integration will find documents for your companies (your API key supports multiple companies.) Like most endpoints, this endpoint supports advanced querying and document deletion (depending on your workflow, you may want to remove an invoice once it has been downloaded to your integration.) To enable invoice reception all you have to do is share your Codice Destinatario (recipient code), so emitters can use it in their documents.

See the receive endpoint page at the API Reference for more information.

Tip

Besides the pull mechanism described above, where your integration routinely checks for incoming invoices, you can also opt for a push workflow. See Webhooks below for more information.

Setting the Codice Destinatario properly

For vendor invoices to be routed through the API, it is necessary to properly configure the Internal Revenue Service portal.

Webhook notification

Webhooks allow a push workflow for your integration, where it is notified as soon as something relevant about your documents happens on the API. The typical use case is being informed about a status update or new incoming invoices. Your integration must expose a dedicated endpoint that will be invoked by the API when the configured event occurs. Webhooks are a powerful feature that is available at no additional cost.

See the webhook page at the API reference for more information.

Event logging

All that happens to your data is logged, and you can retrieve and query all those events anytime at a dedicated log endpoint, allowing for comprehensive, safe audits. For each event, you have plenty of data points available, many of which are queryable: endpoint, request method, API version, company involved, response status code. Events serve as the building blocks for webhooks, too. You can hook a webhook to any event, and your integration will be notified when that event occurs.

See the event endpoint page at the API reference for more information.

Multi-company support

A single API key supports managing one or more sending and receiving entities (companies). A dedicated endpoint allows the management of company entities. When you send an invoice, a company is automatically added for you if missing, so you can start sending documents as soon as an active API key is in your hands.

See the company page at the API Reference for more information.

Free Sandbox

When you register, you receive a test and a live API key. The test key lets immediately and freely access the sandbox environment. You don't need to pay up front to start using the Invoicetronic API. The sandbox is always available for evaluation and/or testing. Once you feel confident that the Invoicetronic API suits your needs, you can choose to purchase credits for the live environment.

To learn more, see the Sandbox section.

Client SDKs

To help you interact with our APIs, we created a set of open source SDKs (Software Developer Kits) for the most common programming languages. SDKs will speed up the integration process. These SDKs provide updated models and methods to contact our APIs with minimal configuration, making it possible to start interacting with the Invoicetronic API within minutes. You only need an active API Key and are ready to go.

To learn more, see the SDKs section.

invoice command line tool

You don't need to learn the API or any programming language to send and receive invoices. We created the invoice command to quickly and intuitively exchange invoice file(s) with the Servizio di Interscambio (SDI) via the command line. Alternatively, you can use general-purpose, well-known tools such as curl.

To learn more, see the CLI Tools section.

Web Dashboard

The Dashboard lets perform some tasks via a web interface. Create and configure webhooks, monitor your event log, manually upload invoices with a simple click, create new restricted API Keys, check the status of your account, purchase credits, and more.

Roadmap

The following features are on our roadmap, and we currently plan to release them in the future.

White labelling

Our convenient white labelling option offers a custom unique Codice Destinatario (recipient code) that sets you apart from the rest. With the personalized code, your integrations use the Invoicetronic API at its fullest while you maintain a unique and autonomous profile with your clients and correspondents.

Restricted API Keys

Registering with the Invoicetronic API will grant you a pair of primary API keys, one for testing and one for the live environment. These two keys have full access rights to the API resources and cannot be deleted.

You can add new keys and assign them the rights you see fit, depending on your use case. For example, you could make a key for a specific integration with only read access. Another scenario is creating a temporary, restricted key you want to lend to a new hire to let them experiment with the API.

All your API keys are linked to your account, and you can manage them from the dashboard.