Automating Lexoffice with n8n: Receipts, Invoices, Contacts

Lexoffice can be automated with n8n, even though there is no official n8n node for Lexoffice: the solution is the HTTP Request node, which talks directly to the public Lexoffice API and retrieves receipts, creates invoices, or synchronizes contacts there. For this you need a personal API key from your Lexoffice account, which n8n sends as a bearer token in the Authorization header, along with a header auth credential stored in the HTTP Request node. The production API has run under the domain api.lexware.io since May 2025 and is limited to a maximum of two requests per second. As of: July 2026.

Why is there no native n8n node for Lexoffice?

Lexoffice is not among the services officially integrated by n8n, which is why workflows have to use the generic HTTP Request node instead of a ready-made Lexoffice node. For such cases, n8n supports several generic authentication methods in the HTTP Request node, including Header Auth, Basic Auth, OAuth2, and Query Auth (n8n documentation on the HTTP Request node). For Lexoffice, Header Auth is the right choice because the API requires bearer token authentication via the Authorization header. The price of this flexibility: endpoints, fields, and error handling have to be rebuilt manually, and whenever Lexoffice changes its API, the workflow has to be maintained independently instead of working automatically with a node update.

How do you authenticate n8n against the Lexoffice API?

Authentication runs via a personal API key, which you generate in your Lexoffice account under the public API settings and send as a bearer token in the Authorization header of every request (Lexware API documentation). In n8n, you set this up in the HTTP Request node by creating a Header Auth credential named Authorization with the value Bearer followed by the key. Two technical points are important for workflow planning:

• Base URL: Since May 26, 2025, the production API has run under https://api.lexware.io; the old lexoffice.io address has since been replaced.
• Rate limit: The API allows a maximum of two requests per second; if this is exceeded, it responds with HTTP 429, which is why larger synchronization runs need a throttled loop or a Wait node in the workflow.

How do you retrieve new receipts from Lexoffice with n8n?

New receipts can be retrieved via the GET endpoint /v1/voucherlist, which can be filtered by query parameters for voucher type, status, and creation or modification date. In n8n, you configure the HTTP Request node with the GET method and the URL https://api.lexware.io/v1/voucherlist, adding parameters such as voucherType, voucherStatus, and createdDateFrom, for example to fetch only open invoices from the last 24 hours. The response is paginated, with a default size of 25 entries per page and fields such as totalPages and totalElements, which is why a complete synchronization needs a pagination loop. A typical pattern: a cron trigger starts the workflow hourly, retrieves new or changed receipts, and writes them to a table or an internal dashboard.

How do you create new invoices in Lexoffice via n8n?

New invoices are created via a POST request to /v1/invoices, where the JSON body contains the customer, invoice line items, and tax rates. In the HTTP Request node, you select the POST method, set the Content-Type to application/json, and pass the invoice body either from previous workflow data or from a Set node that assembles the fields to match the Lexoffice schema. A practical example: an order completion in an online shop triggers an n8n workflow via webhook, which automatically transfers customer data and line items into the format expected by Lexoffice and creates the invoice. The API validates the schema strictly, which is why test runs with real test data are worthwhile before such a workflow goes into production.

How do you synchronize contacts between n8n and Lexoffice?

Contacts can be queried via GET /v1/contacts with filters such as email or name and created via POST /v1/contacts, which enables synchronization between Lexoffice and a CRM or a table. A common pattern uses GET to check whether a contact with a specific email address already exists, and only creates it via POST if needed, to avoid duplicates. For companies that use Lexoffice as accounting software alongside a separate CRM, this saves the double manual maintenance of contact data. Anyone who wants to run such multi-step workflows with error handling, rate limit control, and monitoring on an ongoing basis will find support at NordFlux for the building of n8n workflows, including an assessment of which processes are technically and economically worthwhile in the first place.

Frequently asked questions about Lexoffice and n8n

Is there an official Lexoffice node for n8n?

No, n8n does not offer an official, native node for Lexoffice, which is why the connection runs via the generic HTTP Request node against the public Lexoffice API. This means more configuration effort than with a ready-made node, but technically all core functions such as receipts, invoices, and contacts are accessible via the API. With a Header Auth credential set up once, any number of workflow steps can rely on the same access.

How high is the rate limit of the Lexoffice API?

The Lexoffice API limits requests to a maximum of two requests per second; if this is exceeded, it responds with the HTTP status code 429. In n8n workflows with many records, you should therefore build in a Wait node or a throttled loop so as not to exceed the limit. For larger synchronizations, for example several hundred contacts, this becomes noticeable in the runtime and should be factored into workflow planning.

Which base URL does the Lexoffice API currently use?

Since May 26, 2025, the production Lexoffice API has run under the domain api.lexware.io; the old address under lexoffice.io has since been replaced. n8n workflows that still use the old URL should be switched to the new base URL to avoid errors. The API key itself remains unaffected and continues to be managed in the Lexoffice account.

What happens if Lexoffice changes the API?

Since the connection runs via self-built HTTP requests instead of a maintained n8n node, the workflow has to be adjusted manually whenever there are schema or endpoint changes. That is the price of the flexibility of an individual pattern: there is no automatic update mechanism like an officially maintained node would have. Anyone who does not want to bear this maintenance effort themselves should factor it firmly into the planning.