Connecting to e-Boekhouden.nl

e-Boekhouden.nl runs two entry points side by side, and the choice between them decides how long your integration lasts.

Two generations side by side

e-Boekhouden.nl offers two ways to connect. The older one is a SOAP integration, an earlier technique where your software opens a session first and exchanges messages after that. The newer one is a REST API, the technique the rest of the market has settled on.

The package itself shows which of the two is the old one: in the menu the first is labelled as the old integration in so many words. New work belongs on the REST API, even where an existing connector still runs over SOAP.

If a SOAP integration is already running, that is no reason to hurry, but it is worth knowing. Building something new on the old entry point means building something that will have to be redone.

Getting access

You create the token for the REST API yourself inside e-Boekhouden.nl, under Beheer and then Koppelingen. Watch the labels when you pick: the line marked as the old integration is the SOAP variant, not the one you need.

As with every package: if the administration sits on your accountant's subscription, your accountant creates the token or grants you the right to do so. Arrange that before building starts, because without a token there is nothing to connect to.

What to watch in the design

e-Boekhouden.nl does not publish a hard number of calls you may make per day. That does not mean there is no limit, and it certainly does not mean you can lean on it indefinitely.

Treat the integration as though the limit is there. Send several entries at once rather than one at a time, spread a first load of thousands of rows over time, and let the integration retry calmly when the package does not answer.

That is the behaviour you want with any package anyway. An integration that is considerate towards the system it talks to keeps working when your volume grows or when the vendor tightens their limits.

What we build here

We connect e-Boekhouden.nl to online stores, to time tracking and to custom software, against the REST API. An order or a finished project becomes a sales invoice in the package, and your software can see whether that invoice has been paid.

If something already runs over the old SOAP integration, we look in the intro call at what moving it would cost and whether it has to happen now. After that you get a proposal with one price and one delivery date.

Sources

Frequently asked questions

Do we have to replace our existing SOAP integration right away?

Not right away. If it works and does what it should, it can stay. Do put new work on the REST API, and plan the move for a moment that suits you rather than one that forces you.

Is API access part of our subscription?

Connecting is broadly available at e-Boekhouden.nl, but check it for your own plan inside your account. That is one look at the Koppelingen menu and it saves a surprise halfway through the project.

How many invoices a day can an integration like this handle?

For the volumes of a small or mid-sized business this is not the bottleneck, provided the integration works in batches and retries after a failure. Give us your numbers in the intro call and we will work it out rather than estimate it.

Can you read from e-Boekhouden.nl rather than write to it?

Yes. A client portal showing outstanding invoices is a common example. Reading and writing are separate permissions, and we only ask for what the integration actually needs.