Welcome to the NZRT Wiki Podcast. Today we’re looking at 🔌 Dolibarr REST API Setup.

So let’s talk about how you actually talk to Dolibarr programmatically. Dolibarr ships with a built-in REST API, and that’s the primary way AI agents at NZRT reach into the ERP to read and write data. There’s no WordPress middleman here, no sync scripts running on a schedule — agents call the API directly, on demand, using their own credentials.

First, let’s orient you to where the API lives. The base URL follows a predictable pattern: you start with your Dolibarr server’s domain, then the path goes through the API index file, followed by a version segment. In NZRT’s case the live server is at erp.nzrtnetwork.com, but the pattern is the same wherever you host Dolibarr — domain, then api/index.php, then the version.

Now, what can you actually reach through this API? There’s a solid set of core endpoints. You can list all customers, or pull a single customer by their ID. Same story for invoices — list them all, or drill into one specific invoice. Products work the same way. You can also list HR employees and pull supplier records. So whether you’re building a finance agent that needs to check unpaid invoices, or a customer-facing agent that needs to look up account details, the API has you covered with a clean, predictable URL structure where you swap in the resource name and optionally add an ID.

Authentication is straightforward. Every request needs an API key passed in as a request header. The header name is DOLAPIKEY — spelled out in capitals — and the value is the key itself. So if you imagine a simple HTTP request to fetch customers, you’d attach that header, point the request at the customers endpoint, and Dolibarr handles the rest. You never send a username and password on each call — just that single API key header every time.

Now, where do those API keys live? You need to generate them from the Dolibarr admin panel, and you’ll store a few pieces of information: the endpoint URL itself, the API key, and optionally the username of the Dolibarr user the key belongs to.

Here’s how NZRT specifically handles this, and it’s worth paying attention to because it differs from a generic Dolibarr setup. Credentials are per-agent. Each AI agent in the NZRT stack — so that’s agents like cas, fin, han, and the others — holds its own individual API key. Those keys are scoped to match the module permissions that agent actually needs. A finance agent gets access to invoice and payment endpoints. A customer-facing agent gets access to customer records. They don’t all share one admin-level key. This keeps permissions tight and makes it easy to revoke or rotate a single agent’s access without touching the others.

All those per-agent credentials are stored in Nextcloud, under the Shared CREDS folder. If you’re setting up a new agent or rotating a key, that’s where you go to find and update the relevant credential file.

One more thing worth flagging: agents call the API on demand, in response to tasks or queries. There’s no background WordPress sync happening, no webhooks firing on a timer. When an agent needs data, it makes the call. When it doesn’t, nothing moves. That keeps the integration simple, auditable, and easy to debug — if something went wrong, you check the agent’s API call, not a background job running somewhere in WordPress.

If you want to go deeper, the related topics to look at are the WP-Dolibarr Integration Overview, the WP-Script Core documentation, and the WordPress Pages Map — those will give you the bigger picture of how Dolibarr connects to the rest of the NZRT stack.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.