Publicly documented, usable the same day.
REST over HTTPS, token authentication, webhooks for the other direction — and documentation your IT can read before anything is signed.
Endpoints
- GET /api/v2/customers Read debtors
- POST /api/v2/customers Create and update debtors
- GET /api/v2/journal_entries Read open documents
- POST /api/v2/payments Hand over payments
Webhooks
- reminder.sent A reminder has been sent
- clarification.opened A clarification has been opened
- credit_limit.published A limit has been set
Read and write, authenticated by token.
The API works on the same objects as the interface and under the same permissions. A token belongs to an integration rather than to a person — and what it may see follows the roles and data scopes you give it.
Token authentication
One header, no OAuth dance for server-to-server — and one token per integration, so it can be revoked on its own.
The same objects
Debtors, documents, payments, reminders, clarifications — the same fields the interface shows.
The same permissions
The API extends no permission. What an integration may not see, it does not return.
Public documentation
Endpoints, fields and examples are in the integration portal — no login, no sales call.
The other direction, without polling every minute.
A webhook reports what happened in Bilendo to the address you register — so your systems do not have to ask whether anything changed.
- Events you choose
- Reminders sent, clarifications opened or closed, limits set, master data changed.
- One address per integration
- Configured separately, so one source system does not receive another's events.
- Visible state
- For each integration the interface shows when it last synchronised.
- reminder.sent A reminder has been sent
- clarification.opened A clarification has been opened
- credit_limit.published A limit has been set
And for bulk, the route your ERP already knows.
Not every handover belongs in an API. For whole populations there is the batch interface and file handover over SFTP — with the same fields and the same validation as the single call.
What the API explicitly does not offer.
Anyone planning an integration needs the gaps before they start — not in week three.
- No SDK. There is a documented REST API, not a library we maintain for you.
- No extended permissions. A token sees what its integration may see, and no more.
- No substitute for field mappings. What lands in which field is agreed, not guessed.
- No release over the API. Consequential steps stay with a person.
- No uptime commitment on this page. What is committed is in the contract.
What developers want to know first.
The documentation is public, the first transfer is possible the same day, and a token belongs to an integration rather than to a person. What takes time afterwards are field mappings and the special cases of your landscape, not access.
No, and that is deliberately here: there is a documented REST API with token authentication. A library we would maintain for several languages does not exist — otherwise anyone expecting one has a problem in week three.
Exactly what its integration may see. Roles and data scopes apply to the API as they do to the interface, closed when in doubt. Which is why one token per integration is sensible: it can be revoked on its own without touching anything else.
The state per integration is visible in the interface, including the last sync — that is where it shows. This page makes no promises about retries; what is agreed technically is in the integration documentation and in the contract.
You can deliver and read data, have drafts created and query state. What people release — sending a reminder, handing a document to collection, a limit being set — stays a release in the application and is not bypassed by an endpoint.