Skip to main content
e-invoice.be publishes SDKs for five languages. Each SDK is generated from the OpenAPI specification of the API and gives you typed requests, typed responses, automatic retries and error classes. You do not have to write HTTP calls. All SDKs call the single API host https://api.e-invoice.be. The API key selects the mode: a key of a sandbox company makes the SDK run in test mode, and a key of a production company sends documents on the Peppol network. See Test mode and sandbox companies.

Available SDKs

The TypeScript SDK also runs in Deno 1.28.0 and later, Bun 1.0 and later, Cloudflare Workers and the Vercel Edge Runtime. The README of the repository has the full list.

Install an SDK

The Ruby and Java version numbers above are the versions in each README at the time of writing. Use the README of the repository to find the current version.
The PHP SDK is not on Packagist. Composer installs it from the GitHub repository, as the repositories entry in the sample shows.
The Java coordinates above are the coordinates in the README of the Java SDK. At the time of writing (2026-10-01), the artifact com.e_invoice.api:e-invoice-java is not yet on Maven Central: repo1.maven.org returns 404 for it. If your build cannot find the artifact, see the README of the repository for the current status.

Authenticate

Each SDK reads the API key from the environment variable E_INVOICE_API_KEY. Do not put the key in your source code.
To get an API key, see Authentication.

Validate, create and send a document

The samples do the same operations in each language:
  1. Create a client and read the account of the API key (GET /api/me/).
  2. Validate the invoice JSON (POST /api/validate/json).
  3. Create the document (POST /api/documents/). The document is in the DRAFT state.
  4. Send the document (POST /api/documents/{document_id}/send).
Validation is not a separate mandatory call. POST /api/documents/ rejects a payload that does not pass the same rules. Use POST /api/validate/json while you develop, because it returns all rule failures and the generated UBL.
The samples use the vendor E-INVOICE BV (BE1018265814). Replace vendor_name, vendor_tax_id and vendor_address with the data of your own company. A sandbox company has an assigned VAT number, which you can read from the account response.
The Java SDK is an alpha release. It does not have the account resource (GET /api/me/), thus the Java sample starts with the validation step.
The send call accepts the optional routing parameters sender_peppol_scheme, sender_peppol_id, receiver_peppol_scheme, receiver_peppol_id and email. In Java, the names are in camel case in DocumentSendParams. See Create e-invoices for when to set them. With a sandbox company, the send call does not use the Peppol network. See Test mode and sandbox companies.

Method names for each SDK

In Ruby, the send method has the name send_ with an underscore at the end, because send is a method of each Ruby object.
The TypeScript and Python repositories have a file api.md with the full list of methods.

Versions and the OpenAPI specification

The API has one OpenAPI specification, which is version 1.1.0 at this time. Each SDK is generated from this specification, but each SDK has its own version number. An SDK version number does not agree with the version number of the specification.
  • The TypeScript, Python and Java SDKs follow semantic versioning, with the exceptions that each README gives.
  • The Ruby and PHP SDKs have major version 0. Their README states that the interface can change at any time.
  • A new endpoint can be in the API before it is in an SDK. The API reference always shows the current API. Each README shows how to call an endpoint that the SDK does not have yet.

Report a problem

Report a problem with an SDK in the issues of its repository:

Next Steps

peppol CLI

Validate, create and send documents from the command line

Create e-invoices

Learn the fields of an invoice

Errors and troubleshooting

Handle the errors that the API returns

API reference

See all endpoints and schemas