e-Boekhouden API: connect e-Boekhouden to your webshop, CRM and payments

What you can do with the e-Boekhouden API

• Create sales invoices from your webshop or CRM in e-Boekhouden
• Keep contacts in sync with your CRM
• Deliver mutations and payments from Mollie or the bank
• Fetch outstanding items for reminders or a dashboard
• Items and prices from e-Boekhouden to your webshop

How the integration works

The integration starts a session with the API token and then uses a short-lived session token for every call. The API token itself never goes into a header, only into the session request. After that the integration works with e-Boekhouden's REST objects: contacts, invoices, mutations, ledger and products. Every invoice gets a fixed reference, so retries are safe.

Facts about the e-Boekhouden API

Checked on 2 November 2026 against the official documentation. Limits, prices and versions change; the source is listed per row.

Fact	What the documentation says	Source
Authentication	API token from the account settings (shown once). You start a session with it and receive a session token for the Authorization header; the API token itself only goes into the session request.	e-Boekhouden: OpenAPI v1
Session lifetime	The session token is short-lived; the request returns after how many seconds it expires. No refresh; you start a new session.	e-Boekhouden: OpenAPI v1
Rate limits	Not in the official documentation. Paging: 100 per page by default, 2,000 at most.	e-Boekhouden: OpenAPI v1
Webhooks	Not in the official documentation.	e-Boekhouden: OpenAPI v1
Test environment	Not in the official documentation.	e-Boekhouden: Own API integration
Version	REST API v1 (OpenAPI 3.1) next to an older SOAP integration; an end date for SOAP is not in the documentation.	e-Boekhouden: API reference
Objects	Contacts, invoices, mutations, ledger accounts and balances, cost centres, products and product groups, administrations.	e-Boekhouden: OpenAPI v1
API cost	Not in the official documentation.	e-Boekhouden: Own API integration
n8n	No built-in node and no community node found; the integration runs through an HTTP step in n8n.	n8n documentation

What you need on your side

• An administrator who can create an API token in the e-Boekhouden account settings
• The VAT codes and ledger accounts per item or service, aligned with your accountant
• A fixed reference per order and per contact, so nothing is booked twice
• Access to the webshop, CRM or payment service on the other side

Where it often goes wrong, and how I prevent it

• Expired session: the session token is short-lived. The integration starts a new session in time instead of waiting for an error.
• Token in the wrong place: the API token belongs only in the session request. In a header it does not work and causes a security error.
• VAT codes per country: e-Boekhouden works with VAT codes per country with validity dates. I record those up front.
• Duplicate contacts: without a fixed key you get duplicate contacts. I match on a fixed number, not on name.

In practice

An e-Boekhouden integration is not yet listed as In production with me. The approach is the same as for Moneybird: a fixed reference per invoice and contact, a session that is renewed in time, and a plain-language notification when a booking fails.

What it costs

I build an e-Boekhouden integration as one scoped process for a fixed price, from €750. Maintenance and monitoring are a monthly fee: n8n management from €250 per month, server management €145 per server. In the free assessment we work out your process. All prices and what is included →

What I do not do

• I do not do your bookkeeping; the VAT and ledger mapping comes from you or your accountant.
• I no longer build new integrations on e-Boekhouden's SOAP integration.
• I never put the API token in a header or log file; it stays in n8n's secure storage.

Frequently asked questions about the e-Boekhouden API

Does n8n have an e-Boekhouden node?

No, and no community node was found either. I connect e-Boekhouden through the REST API with an HTTP step in n8n.

Do you use the SOAP or the REST integration?

The REST API v1. e-Boekhouden still has an older SOAP integration, but for new work I build on REST. An end date for SOAP is not in the documentation.

How does access to the API work?

You create an API token in your account settings; it is shown once. The integration exchanges that token for a short-lived session token and works with that.

Does e-Boekhouden have limits or webhooks?

Neither is in the official documentation. The integration therefore checks at fixed intervals and works in batches, so e-Boekhouden is not loaded unnecessarily.

What happens when an invoice does not arrive?

The invoice goes to a queue and you get an error email with the order number and the error code from e-Boekhouden. Temporary errors are retried automatically.