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

If you’ve been working with Dolibarr and you want to connect it to other systems, pull data out programmatically, or automate repetitive tasks, the REST API is your main tool. It exposes pretty much every entity inside Dolibarr — customers, invoices, products, orders — all through standard web requests. Let’s walk through how it works.

First, the base URL. Every API call you make starts at the same address, which is your Dolibarr instance’s domain, followed by the path api/index.php and then a forward slash. So if your Dolibarr is hosted at erp.yourcompany.com, every endpoint you call will begin with erp.yourcompany.com/api/index.php/ and then whatever resource you’re targeting. That consistent pattern makes it easy to reason about — once you know the base, you just tack on the entity name you want to work with.

Now, authentication. Dolibarr’s REST API uses API key authentication. When you make a request, you include a special HTTP header called DOLAPIKEY, and the value is your personal API key. You don’t need to deal with OAuth flows or token exchanges — it’s a single header on every request. Your API key is something you generate inside the Dolibarr admin interface and then store somewhere secure, like a credentials file or an environment variable. If you’re working in an automated script or agent, you’ll want to pass that key in programmatically rather than hardcoding it anywhere that might end up in version control.

Let’s talk about the key endpoints, because this is where you’ll spend most of your time. Think of each endpoint as the address for a specific type of data in Dolibarr.

There are six main ones covered in the wiki. The first is thirdparties, which covers your customers and suppliers. You can send GET requests to retrieve records, POST to create new ones, and PUT to update existing ones. The second is products, which works the same way — GET, POST, and PUT for reading, creating, and updating your product catalogue.

Third is invoices. Again, GET, POST, and PUT. If you’re building any kind of billing automation — say pulling invoice data into a reporting tool or creating invoices from an external order system — this is the endpoint you’ll be hitting most. Fourth is orders, specifically customer orders, with the same three methods available.

The fifth endpoint is bankaccounts. This one is read-only, so you only have GET available here. It’s useful if you need to retrieve account details as part of a reconciliation process or a financial summary. And sixth is users, also GET only, which lets you pull user records from Dolibarr — handy if you’re syncing user data between systems or need to look up user IDs for assigning tickets or tasks.

So to summarise the pattern: most of the business-critical entities — thirdparties, products, invoices, orders — support full read-write access through GET, POST, and PUT. The more sensitive or administrative resources like bank accounts and users are restricted to read-only access through GET.

One more thing worth mentioning: Dolibarr ships with an interactive API explorer built on Swagger UI. You reach it by going to your instance’s API base path and then adding the word explorer at the end. So it would be your domain, then api/index.php/explorer. This gives you a browser-based interface where you can browse every available endpoint, see what parameters each one accepts, and even fire off test requests directly from the page. If you’re new to the API or you’re trying to figure out the shape of a response before writing code, the explorer is genuinely the fastest way to get familiar with it.

For bulk data needs — like exporting large sets of records for reporting — the wiki points you toward the Data Export feature as an alternative. The REST API is great for targeted, programmatic access and integration work, but if you need to dump thousands of rows at once, the built-in export tools might be a more practical starting point.

To pull it all together: when you’re integrating with Dolibarr, your request always goes to the api/index.php base path, you always include your DOLAPIKEY header for authentication, and you choose your endpoint based on the entity you’re working with. Whether you’re reading customers, creating invoices, updating products, or pulling order data, the structure is consistent and predictable across the board.

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