EasyAPI - API REST professionnelle pour Dolibarr (32 domaines du cœur) + MCP

L’API REST que Dolibarr devrait fournir de série

EasyAPI réimplémente les 32 domaines du core de Dolibarr (ventes, achats, stock, comptabilité, projets, RH, associations…) sur un contrat unique : le même envelope de réponse, la même taxonomie d’erreurs, l’idempotence sur toute écriture et un serveur MCP pour les agents IA. Vos permissions et votre ACL Dolibarr restent maîtresses.

Le même envelope, les mêmes codes et les mêmes filtres sur les 32 domaines. On l’apprend une fois et ça sert pour tout : il n’y a pas une façon différente de paginer, de filtrer ou de lire l’erreur selon la ressource que vous touchez.

Ce que demande l’agent d’IA attend votre confirmation

Avec la confirmation humaine activée, une écriture demandée par un agent via MCP ne s’exécute pas. Elle attend dans Outils › Actions en attente (IA) avec ses données et un aperçu, et elle n’a lieu que lorsque la personne qui a connecté l’agent clique sur Confirmer.

• Vous choisissez ce qui attend. Toutes les écritures, ou seulement l’envoi d’e-mails et les suppressions. L’option est désactivée par défaut : la mise à jour ne change rien.
• L’agent ne peut pas se confirmer lui-même. La confirmation n’existe pas pour le MCP : elle se fait dans Dolibarr ou via l’API REST (POST /mcp/pending/{token}/confirm), et seule la personne qui a demandé l’action peut la donner.
• Une seule fois, avec expiration. Chaque action se confirme une fois et expire au bout de 10 minutes ; le délai va jusqu’à 24 heures.
• E-mails marqués. Un e-mail envoyé après confirmation porte X-AI-Generated et X-AI-Reviewed.

Qui vous doit quoi et depuis quand, et le prix que l’ERP appliquerait à chaque client

La version 2.25 a apporté des indicateurs métier qu’il fallait jusqu’ici reconstituer en additionnant les factures à la main. Le MCP, lui, indique à l’agent ce que fait chaque opération avant qu’il ne l’appelle.

• Ancienneté des créances. GET /invoices/kpis/aging et GET /supplier-invoices/kpis/aging répartissent le reste dû entre non échu, 1-30, 31-60, 61-90 et plus de 90 jours. Les tranches se règlent avec ?buckets=0,15,45 et ?group=thirdparty donne le détail par tiers. Ils suivent l’ACL des listes : le commercial qui ne voit que ses clients ne voit que la dette de ces clients.
• Délais moyens et vrai reste dû. /invoices/kpis ajoute dso et /supplier-invoices/kpis ajoute dpo, les délais moyens d’encaissement et de paiement sur les 90 derniers jours. Les KPI outstanding et overdue additionnent ce qui reste vraiment dû : ils déduisent les paiements partiels, les avoirs et les acomptes avec le même calcul que getRemainToPay() du cœur.
• Prix effectif par client. GET /products/{id}/price?socid=&qty= renvoie le prix que l’ERP mettrait sur la ligne pour ce client et cette quantité, avec TVA, surtaxe et retenue à la source, les totaux et l’origine du prix : base, price_level, customer_price ou quantity.
• Des erreurs sans SQL. Le message du moteur de base de données reste dans le syslog avec le request_id, et la réponse porte un code exploitable : un doublon donne un 409 avec reason: duplicate_record, et un verrou un 503 avec Retry-After: 2 pour réessayer.
• Chaque opération déclare son effet. x-effect indique si elle lit (read), écrit dans l’ERP (internal), sort vers l’extérieur (external) ou n’a pas de retour arrière (irreversible), et le MCP le traduit en readOnlyHint et destructiveHint. Les suppressions par MCP peuvent être interdites dans la configuration (EASYAPI_MCP_ALLOW_DELETE) ou utilisateur par utilisateur, et c’est le réglage le plus strict qui s’applique.
• IBAN masqué. Par MCP, l’IBAN, le numéro de compte et la référence du mandat des comptes bancaires des tiers ne montrent que les 4 derniers caractères. Par REST, rien ne change.

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 n’est pas un module publié et oublié : la version actuelle est la 2.28.0 et chaque livraison ajoute des tests qui tiennent ce qu’elle corrige. La 2.28 apporte un test pour chaque règle de la confirmation humaine, vérifié en cassant la règle exprès, un test navigateur de la page des actions en attente et une vérification HTTP sur Dolibarr 15, 18 et 24. En plus des tests, chaque release passe une QA sur des instances réelles de Dolibarr avant publication.

Ça colle à ce que vous devez intégrer ?

Racontez-nous votre cas et on vous dit si EasyAPI vous sert — et sinon, on vous le dit aussi.