EasyAPI - Professional REST API for Dolibarr (32 core domains) + MCP

The REST API Dolibarr should ship with

EasyAPI reimplements the 32 core domains of Dolibarr (sales, purchasing, stock, accounting, projects, HR, membership…) on a single contract: the same response envelope, the same error taxonomy, idempotency on every write and an MCP server for AI agents. Your Dolibarr permissions and ACL still rule.

The same envelope, the same codes and the same filters across the 32 domains. You learn it once and it works for all of them: there is no different way to paginate, filter or read the error depending on the resource you touch.

What the AI agent asks for waits until you confirm it

With human confirmation on, a write that an agent asks for through MCP does not run. It waits in Tools › Pending actions (AI) with its data and a preview, and it only happens when the person who connected the agent presses Confirm.

• You decide what waits. Every write, or only email sending and deletions. The option comes off, so upgrading changes nothing.
• The agent cannot confirm itself. Confirmation does not exist for MCP: it is done in Dolibarr or through the REST API (POST /mcp/pending/{token}/confirm), and only the person who asked for the action can give it.
• Once, and with an expiry. Each action is confirmed once and expires after 10 minutes; the limit goes up to 24 hours.
• Marked emails. An email sent after confirmation carries X-AI-Generated and X-AI-Reviewed.

Who owes you what and since when, and the price the ERP would charge each customer

Version 2.25 brought business figures you used to build by adding up invoices by hand. The MCP also tells the agent what each operation does before it calls it.

• Debt ageing. GET /invoices/kpis/aging and GET /supplier-invoices/kpis/aging split what is outstanding into not yet due, 1-30, 31-60, 61-90 and over 90 days. You change the buckets with ?buckets=0,15,45, and ?group=thirdparty gives the breakdown per third party. They follow the same ACL as the lists: a sales rep who only sees their own customers only sees those customers' debt.
• Days to collect and pay, and the real balance. /invoices/kpis adds dso and /supplier-invoices/kpis adds dpo, the average days to collect and to pay over the last 90 days. The outstanding and overdue KPIs add up what is really left to pay: they deduct partial payments, credit notes and deposits with the same calculation as the core's getRemainToPay().
• Effective price per customer. GET /products/{id}/price?socid=&qty= returns the price the ERP would put on the line for that customer and that quantity, with VAT, surcharge and withholding tax, the totals and where the price comes from: base, price_level, customer_price or quantity.
• Errors without SQL. The database engine's message stays in the syslog with the request_id, and the response carries a code you can act on: a duplicate is a 409 with reason: duplicate_record, and a lock is a 503 with Retry-After: 2 so you can retry.
• Every operation declares its effect. x-effect says whether it reads (read), writes inside the ERP (internal), reaches outside (external) or cannot be undone (irreversible), and the MCP maps it to readOnlyHint and destructiveHint. Deletes through MCP can be forbidden in the setup (EASYAPI_MCP_ALLOW_DELETE) or user by user, and the stricter setting wins.
• Masked IBAN. Through MCP, the IBAN, the account number and the mandate reference of third-party bank accounts come back with only the last 4 characters. Nothing changes over REST.

curl -X POST "https://tu-dolibarr.com/custom/easyapi/api/invoices" \
  -H "DOLAPIKEY: tu_clave" \
  -H "Idempotency-Key: pedido-4417" \
  -H "Content-Type: application/json" \
  -d '{"socid": 128, "lines": [{"fk_product": 55, "qty": 2, "subprice": 49.90}]}'

{
  "success": true,
  "data": {
    "id": 902,
    "ref": "(PROV902)",
    "socid": 128,
    "statut": 0,
    "total_ttc": 119.76,
    "lines": [ { "id": 3311, "qty": 2, "subprice": 49.90 } ]
  }
}

{
  "success": false,
  "error": {
    "type": "validation_error",
    "code": 422,
    "message": "Validation failed",
    "fields": { "socid": "does not exist" },
    "request_id": "req_7f3a91c2",
    "doc_url": "https://easysoft.es/docs/api#validation_error"
  }
}

EasyAPI is not a module that gets published and forgotten: the current version is 2.28.0 and every delivery adds tests that hold down what it fixes. 2.28 brings a test for every rule of the human confirmation, checked by breaking the rule on purpose, a browser test of the pending actions page and an HTTP check on Dolibarr 15, 18 and 24. On top of the tests, every release goes through QA against real Dolibarr instances before it is published.

Does it fit what you need to integrate?

Tell us your case and we will tell you if EasyAPI works for you — and if it does not, we will tell you anyway.