Dolibarr REST API: connect your ERP to your website and online shop

What the REST API changes in a small business's daily work

An order arrives on the online shop. Someone copies it into Dolibarr, creates the customer if it does not exist, then adjusts the stock by hand. One typo in an address, one forgotten line, and the delivery goes wrong. The Dolibarr REST API removes these manual steps. It exposes the ERP's objects (third parties, products, quotes, orders, invoices, contacts, projects) as web addresses that other software can read or modify, exchanging data in JSON format. Your website, your shop or an internal tool then talk directly to Dolibarr, with no human data entry. The API does not replace the interface: it works alongside it, with the same permissions and the same business rules. The gain is less about speed than about reliability: data is entered once, at the source, then flows from there.

Enabling the API and preparing a dedicated access

The API is provided as a module. You enable it from Dolibarr's module list, like any other, then check that the web server lets calls through to the API entry point. On managed hosting, this is often already in place. On an internal server, URL rewriting is the most common blocking point. Next, never connect your tools to an employee's account. Create one technical user per connected application, for example one for the shop and one for the website. Each receives its own access key, personal to that account. You will then know who wrote what in the history, and you can cut one access without affecting the others. If you are unsure about the setup, our implementation team can prepare this foundation with you.

Securing exchanges before the first call

An open API is an extra door onto your commercial data. A few rules prevent most problems. Expose it over HTTPS only, never in clear text, because the key travels with every request. Give each technical user only what it needs: a shop that creates orders does not need to delete invoices. Keep keys in the applications' configuration, not on a public page or in a file shared by email. Change a key as soon as a service provider leaves the project. If the calling tools have stable IP addresses, restrict access at server level. Also keep Dolibarr up to date: security patches matter as much as settings. Our article on securing a production instance covers these points on the server side.

Testing before connecting anything

Never connect production directly. Copy your database to a test instance, create a technical user there and run your first tests with a standard request tool. Start with a simple read, for example the product list. Then try a creation: a dummy third party, a test order. Look at the response. The API's error codes are explicit and tell you whether the key is rejected, a required field is missing or the object does not exist. Dolibarr also provides an API explorer page, which lists the available endpoints according to the active modules. Use it as your reference rather than guessing field names. Once the scenarios are validated on the copy, you replay the same calls in production, with a separate key.

• Copy the production database to a test instance.
• Create a technical user with limited permissions.
• Read a list, then create a dummy object.
• Deliberately trigger an error to see the response.
• Replay the validated scenario in production with a different key.

Which exchanges to automate first

Start with the flows that recur every day and are costly when they go wrong. First candidate: orders from the shop to Dolibarr, with customer creation or matching. Second: stock and prices, in the opposite direction, so the online catalogue reflects reality. Third: contact and quote requests from the website, which become third parties and opportunities without re-keying. Delivery and payment statuses sent back to the customer come later. One flow at a time, validated over a few weeks, is better than one big simultaneous project. If your business is mainly commercial, our solutions for commerce page shows how these exchanges fit into the rest of your management.

Common pitfalls in the field

The first pitfall is duplicates. Without a shared identifier, one person becomes three third parties. Choose a stable matching key, such as the email address or an external reference, and apply it everywhere. Second pitfall: flows in both directions. If the website and the ERP modify the same field, the last one to write wins. Name one source of truth per data item: stock comes from Dolibarr, the marketing description comes from the website. Third pitfall: no recovery on error. A request that fails at night must be replayed and reported, not lost. Plan for a log and an alert. Finally, think about volumes: thousands of simultaneous calls can slow down the users' interface. Spread out synchronisations and avoid reading the full catalogue every minute.

Taking action: scope your first flow

Take an hour with the person who re-keys the most data. List the tools involved, the direction of each exchange, the field used as identifier and the frequency you want. Choose a single flow, usually the shop's orders. If you prefer to trigger actions as soon as an event occurs in Dolibarr, the DolicraftWebhook module sends notifications to automation tools, alongside the API. For a technical scoping of your case, custom connectors or a security review, contact Dolicraft and describe your current tools. We will tell you what is a matter of configuration and what requires development.