How to set up e-Boekhouden API access

This guide is for you, the Apideck customer building an integration on e-Boekhouden.nl. It covers the one-time setup on your side, how an API token is generated, and what your consumers are asked for when they connect.

The short version is good news: e-Boekhouden has no OAuth flow and no app registration. There is no developer portal to sign up for, no client ID or client secret, no redirect URL, and no certification or partnership step to clear before you can call the API. Access rests on a single credential — a personal API token that an administrator generates inside their own e-Boekhouden account — and it is self-service from the first minute.

That has one consequence worth reading twice: this connector has no shared, application-level credential for you to configure. On an OAuth connector you paste a client ID and secret into the Apideck Dashboard once, and every consumer authorizes against it. Here, every connection carries its own token, supplied by the consumer in Vault.

Credential	Who creates it	Where it goes
Application-level credential	None exists for this connector	Nothing to configure in the Apideck Dashboard
API token (personal access token)	Each consumer, in their own e-Boekhouden administration	Vault, on the consumer's own connection

So your job is to enable the connector, generate a token for your own test administration, connect it in Vault so you can build against it, and tell consumers what to expect. There is nothing for you to hold on their behalf.

Before you start

An e-Boekhouden.nl administration you can log in to as an administrator. This is the account that generates tokens. Any regular administration will do — no separate developer account.
A way to test. e-Boekhouden runs a single environment: there is no separate sandbox product, so every token is generated against, and every call is made to, a real administration. Every e-Boekhouden plan includes a 14-day free trial, and that trial administration is the practical way to build and test before committing to a paid plan. Plans and pricing are on the Overview tab.
An Apideck account with the e-Boekhouden connector available under Configuration → Accounting → e-Boekhouden.

That is the whole prerequisite list. There is no application form, no approval queue, and no minimum-customer threshold to meet.

1. Enable the connector in Apideck

Open the Apideck e-Boekhouden connector settings in the Apideck Dashboard and enable the connector for your integration.

There is nothing to paste on this screen for e-Boekhouden — no client ID, no client secret, and no redirect URL to register on the e-Boekhouden side. If you have set up an OAuth connector before and are looking for the Use your own client credentials section, it does not apply here: this connector authenticates with a per-connection token instead.

2. Generate an API token for your own test administration

Do this once for the administration you want to build against. Your consumers repeat the same steps in their own accounts.

Log in to e-Boekhouden.nl.
Go to Beheer → API-token. The exact path varies slightly by account type: on some accounts the token screen sits a level deeper, under Beheer → Inrichting → Koppelingen, and accountant environments reach the same screen via Accountant → Instellingen → Koppelingen. If your account's screen lists two entries under an API heading, choose e-Boekhouden API — the REST API this connector uses — and not API/SOAP (oud), which belongs to e-Boekhouden's older SOAP webservice; a token created against the legacy entry fails on its first REST call.
Add a new token. Give it a recognizable name (for example, the name of your integration) so it is obvious later what the token is for, and set the validity period you want.
Copy the token the moment it is displayed. It is shown only once, and there is no way to view it again afterwards. If you lose it, or paste it incompletely, delete that token and create a new one.

Treat the token like a password. Its destination is Vault (next section) — if you also keep a copy outside Vault while building, keep it in your secret manager, never in source control or a ticket.

3. Connect your test token in Vault

A token on its own does nothing until it is attached to a connection. To build against your own administration, create a connection for a test consumer in Vault:

Open Vault in the Apideck Dashboard and pick (or create) a consumer to test with.
Add the e-Boekhouden connection and paste the token from section 2 into the API Access Token field.
Save the connection, then confirm it works with a read against the unified Accounting API — a list call on ledger accounts or customers is the quickest check.

The connection guide walks through those fields step by step. It is written for your consumers, but the flow is identical for your own test connection, so use it rather than a separate procedure — and it is the page to send customers to when they connect.

4. Know how the token behaves before you hand the process to consumers

Four properties of an e-Boekhouden token decide how your integration ages. None of them are obvious from the token screen.

You choose the validity period at creation. e-Boekhouden does not impose a fixed lifetime — the person creating the token sets how long it lasts (for example, 12 months). When that date passes, every call on that connection starts failing until a new token is generated and saved in Vault. Set your own calendar reminder ahead of the expiry date, and advise consumers to do the same, rather than discovering it through failed syncs.
It is shown only once. There is no "reveal" action. A lost token is replaced, not recovered.
A password change does not invalidate it. This surprises people in both directions: a consumer who rotates their e-Boekhouden password does not break the connection, and a consumer who thinks changing their password revoked API access has not revoked it. Deactivating or removing the user account that owns the token is what invalidates it.
One token belongs to one administration. A consumer who runs several administrations generates a separate token in each, and gets a separate connection per administration (one such walkthrough states it plainly: "Het token hoort bij één administratie. Voer je meer administraties, maak dan per administratie een eigen token aan."). Size multi-entity customers accordingly: N administrations means N connections, not one connection with an administration selector.

5. What your consumers do (and what you never touch)

Each consumer generates their own token in their own e-Boekhouden administration, following the same steps as section 2, and pastes it into Vault when they connect. Send them to the connection guide for the consumer-facing version of those steps.

Two things follow from that split:

You never need to see, collect, or store a consumer's token. It goes straight into Vault, where connection settings are stored encrypted and masked. Asking a consumer to email you their token is both unnecessary and worse for them than the built-in flow.
Your own token is not a substitute. Because a token is bound to the administration it was created in (section 4), using yours for a customer's connection would read and write your books, not theirs. There is no equivalent of an OAuth app credential that spans accounts here.

When you build the connect experience, plan for consumers who are not the finance administrator: the person who clicks Connect in your product may not be the person with Beheer access in e-Boekhouden. Telling them up front that they need an administrator to generate the token saves a round trip.

6. Authentication at runtime — nothing to build

Apideck handles the rest of the authentication for you. The long-lived token the consumer supplied is exchanged for a short-lived session token against e-Boekhouden's session endpoint, and that session token is what is sent on each downstream call. Apideck caches it and obtains a fresh one when it expires.

You do not need to schedule a refresh job, store a session token, or implement any part of the exchange. The only credential lifecycle you and your consumers own is the long-lived token's own validity period, covered in section 4.

FAQ and troubleshooting

I want to list or promote my integration with e-Boekhouden — who do I talk to? e-Boekhouden's API-koppeling page invites integration builders to get in touch about implementing their koppeling — that is a commercial conversation about working together, not a prerequisite for calling the API (see the Overview tab for the partnership/approval requirements). Use the contact route on that page and ask your e-Boekhouden contact what the process and timeline look like.

Where do I paste the API token in the Apideck Dashboard? Not in the connector settings — this connector has no application-level credential field. The token is a per-connection setting, entered in Vault on a consumer's connection, including the test connection you create for yourself in section 3.

A connection that worked for months suddenly fails on every call. Check the token's validity period first — that is the most common cause, because the expiry date was chosen when the token was created and nothing warns you as it approaches. The other cause is the owning user account having been deactivated or removed in e-Boekhouden. A password change on that user does not invalidate the token, so rule that out rather than chasing it. The fix in both cases is the same: generate a new token and update the connection in Vault.

A brand-new token is rejected immediately. Confirm the token was created for e-Boekhouden's REST API. e-Boekhouden also runs a legacy SOAP webservice, which issues its own separate credentials, and those do not authenticate against the REST API this connector uses. Also confirm the whole token was copied — it is shown once, and a truncated paste looks identical to a wrong token.

Can I try the connector before paying for an e-Boekhouden subscription? Yes — see the Overview tab for free-trial and pricing details. An API token can be generated in a trial administration, so you can build and test end to end at no cost.

A consumer has several administrations and only one connected. That is expected — see section 4: a token is bound to a single administration, so each additional administration needs its own token and its own connection.

For anything on the Apideck side of this setup, contact Apideck Support. For token screens, account deactivation, and subscription questions, e-Boekhouden's own support is the right route.

Reference

e-Boekhouden API documentation — the official REST API reference
e-Boekhouden API-koppeling page — the vendor's integration overview and contact route
e-Boekhouden.nl login — where tokens are generated, under Beheer
Apideck e-Boekhouden connector settings — enable the connector for your integration
Connection guide — the consumer-facing steps to send your customers