Documentation API REST

@timmy63

Merci pour ton retour.
Ce qui me pose problème c’est la création du fichier API en lui même, je commence a comprendre la structure et comment se passent les echanges, en revanche je ne sais pas quoi faire de ce fichier.

Pour ce qui est des variables contacts a interroger et récupérer, je viens enfin de trouver le fichier api_contacts.class qui ne se trouvé pas dans contact mais dans société …

@Eurochef
D’accord, je comprends mieux. Mon dolibarr est sur un hébergement mutualisé (OVH), donc l’explorer « fonctionne » à moitié.
Cependant, pour des raisons de test, nous avons installé un dolibarr en local (et là l’explorer fonctionne bien), pour l’intégration de 3CX.
Nous sommes en train de finaliser notre template (3CX), je vous tiens informé dans la journée, nous allons effectuer des test d’intégration aujourd’hui même… Mais ça semble être sur la bonne voie. :happy:

1 J'aime

Bonjour,

Merci beaucoup pour cette contribution. Grâce à elle, je viens de créer une première application utilisant l’API de Dolibar (sous PHP Symfony) et tout fonctionne parfaitement.
Pour faciliter le travail de mes utilisateurs, j’ai décidé de rajouter une option dans le menu de Dolibarr pour appeler cette nouvelle application. Ça fonctionne également.
Ce qui me manque c’est la possibilité de n’autoriser l’appel de mon application que depuis Dolibarr et d’empêcher son appel depuis l’extérieur en utilisant directement son URL depuis un navigateur.
Une solution serait de l’intégrer dans un plugin mais je n’ai pas trop d’expérience et je ne suis pas certain qu’un développement avec Symfony s’intègrera aisément dans un plugin. Le facteur temps est également un point important.

Si quelqu’un a une petite idée, elle sera la bienvenue.
D’avance merci.

Salut @Jacques83300

Une solution « simple » que tu peux mettre en œuvre c’est d’ajouter un paramètre GET aux requêtes de ton appli symfony. Pour chaque requête dans ton appli Symfony, tu peux par exemple attendre un paramètre secretKey qui sera égal à une clé secrète que tu définies arbitrairement et que tu vérifies systématiquement. Pour les appels depuis Dolibarr, tu passes ce paramètre dans l’URL que tu ajoutes au menu par exemple

https://monAppSymfony.example/monController/monAction?secretKey=FWt0kPygbzGHVveWWkSGUkgTqWtIqURt
C’est une solution « rapide » mais il est possible de faire mieux et plus sécurisé bien évidement :wink:

Bonjour @jtraulle,

Merci ta réponse rapide et ta solution simple et efficace.
Eventuellement, je peux utiliser comme clé l’APIKEY nécessaire pour accéder à l’API de Dolibarr. Cette clé est actuellement stockée dans mon application. Sans cette clé correcte, Dolibarr refusera les requêtes.
Qu’en penses-tu ?

Je reste ouvert à d’autres solutions même si je pense intégrer celle-ci dans un premier temps.

Pour ma part, j’utiliserais une clé secrète distincte et sans rapport avec la clé d’API Dolibarr.

Dans l’éventualité où la clé que tu utiliseras fuiterait / serait récupérée (fuite d’access log ou autre), avec une clé distincte, elle ne permettrait que d’exécuter les choses que tu as implémentées dans ton appli Symfony (exécuter des requêtes via ton application sans y être autorisé).

Alors que si tu utilises la clé d’API Dolibarr directement, cela permettrait à l’utilisateur ayant récupéré la clé d’utiliser l’API Dolibarr directement (accès à l’ensemble des endpoints de l’API pour lesquels l’utilisateur Dolibarr lié à la clé d’API a accès au niveau des permissions/autorisations définies pour l’utilisateur).

1 J'aime

Je pense que ton explication est pleine de sagesse et que je vais suivre ta proposition.

1 J'aime

Bonjour,

J’ai déjà fait un backoffice pour des commerciaux en php et l’api rest Dolibarr.
L’utilisateur peut télécharger le PDF directement. le document est en base 64.

ci-joint quelques pistes :

$doc = [
            'module_part' => commande,
            'original_file' => $file . '/' . $file . '.pdf',
            'doctemplate' => 'einstein_shipping',
            'langcode' => 'fr_FR',
        ];

$reponsesBuild  = $this->postData('/api/index.php/documents/builddoc' , $doc);
$data = $this->processFileName($reponsesBuild);

$bin['data'] = base64_decode($data['content']);
$bin['name'] = $data['filename'];

puis charger le $bin dans un Content-type: application/pdf

Bonjour à tous,

Je viens participer à ce fil en vous posant une petite question.
Je fais appel à l’API pour générer des factures, les classer au statut payé et les envoyer par mail.
Le chaîne fonctionne pas trop mal, mais je bloque sur le paiement. Les informations ne sont pas toutes intuitives, et l’erreur ne relate que peut d’informations.
Quand je passe les paramètres suivants

{ 
"arrayofamounts":
    {
         "56": 148
    },
"datepaye": 1589465145,
"paiementid": 6,
"closepaidinvoices": "no",
"accountid": "9"
}

J’ai l’erreur suivante qui s’affiche. Or il n’est jamais question d’un rowid qui fait la liaison à la banque, et ce problème n’est pas présent quand je saisis le paiement directement sur Dolibarr. Il semblerait que ce soit lié à paiementid (donc ici CB = rowid 6 dans le dictionnaire) mais qui n’est pas visible par l’API

Bad Request: Add payment to bank error : this->rowid not defined

@Goldz ça fait déjà 5 jours et j’espère que tu as trouvé ta réponse, mais pour ma part, il n’y a pas de raison que tu ne puisses pas :wink:

Bonjour,
je suis surpris de voir un arrayofamounts.
Quand je consulte la version 11, j’ai le prototype suivant :

{
  "datepaye": "string",
  "paiementid": 0,
  "closepaidinvoices": "yes",
  "accountid": 0,
  "num_paiement": "string",
  "comment": "string",
  "chqemetteur": "string",
  "chqbank": "string"
}

Je ne comprends pas en particulier l’index 56.

Je suis également en version 11.0.3.
L’explorer REST me donne le schéma suivant sur lequel je me suis basé entre autres:

{
« arrayofamounts »: [
« string »
],
« datepaye »: « string »,
« paiementid »: 0,
« closepaidinvoices »: « yes »,
« accountid »: 0,
« num_paiement »: « string »,
« comment »: « string »,
« chqemetteur »: « string »,
« chqbank »: « string »
}

En passant, par le plus grand des hasard, je me suis débloqué aujourd’hui.
Pour répondre à ta question, l’index 56 correspond à l’ID de la facture, il faut bien vérifier que le montant restant à payer n’est pas dépassé sinon on se fait refouler.
J’avais mal interprété le warning

Warning: Take care that all invoices are owned by the same customer. Example of value for parameter arrayofamounts: {« 1 »: « 99.99 », « 2 »: « 10 »}

Et en fait l’accountid est celui du compte bancaire sur lequel on exécute le paiment et non l’id du client.

OK,
Mais c’est pour quelle requête ?
J’ai regardé invoices/{id}/payments en POST

C’est pour la requête : /invoices/paymentsdistributed
Le truc c’est qu’ayant parfois des acomptes sans régler la facture complète ou des règlements sur plusieurs factures, je préfère cet appel.
Que le invoices/{id}/payments règle la totalité de la facture.

Bonjour,

une très bonne chose dans la V.3.9 -- la REST API.
Par contre, aucune doc dessus ;( surtout sur les méthodes PUT.

Qqn aurait-il expériece avec REST API de Dolibarr? Je suis notamment intéressé par l’API /invoice/ – je n’arrive pas à ajouter des produits à une facture-brouillon via la méthode PUT…

Merci

Bonjour,

Je n’ai pas encore testé mais il y a un début de docs dans le README.md.

oui, on l’avait vu, mais elle n’est pas suffisante :unhappy:

Petit up’ sur le sujet…

Je suis en effet en train de m’intéresser de près à l’API REST (plutôt que SOAP), mais le manque de documentation est bloquant. A savoir que je cherche à faire 4 « types » de requêtes sur l’API :

  • Créer des clients (privés, pas société)
  • Créer des factures pour ces clients
    [li]Créer les paiements pour ces factures[/ii]
  • Accéder aux PDF des factures

J’ai réussi à créer des brouillons d’éléments (j’ai essayé factures et clients). En revanche, trouver la correspondances et la liste des champs à inclure dans la requête relève vraiment de la chance.

Est-ce qu’il existe une liste des champs disponibles/obligatoires à inclure dans chaque requête ? Même dans le code, pas nécessairement un PDF tout beau…

Ensuite, sauf erreur de ma part, il n’y a pas d’API prévue pour retourner le PDF d’une facture ? Je peux y accéder autrement, mais d’une façon pas très propre que je préfèrerais éviter.

Bonsoir,

L’api « passe » par les classes pour créer/récupérer les données. Il suffit donc de regarder la classe correspondant au besoin.
Par exemple, pour les clients, il faut regarder la classe societe.class.php. Pour créer un tiers de type Particulier, il faut passer le paramètre typent_id avec une valeur 8.

Effectivement, la récupération des PDF n’est pas prévu (pour le moment ?)

Merci pour l’info, je vais creuser de ce côté.

J’avais d’abord pensé à me baser sur la doc de l’API SOAP pour en déduire la liste des champs de l’API REST. J’ai donc fait quelques tests, notamment pour la création d’un client. Pour lui assigner un pays (France, en l’occurence), je n’ai eu d’autres choix que de préciser le « country_id » à 1. Ni le pays en texte complet (France), ni le country_code (FR ou même FRA) n’ont été pris en compte. Est-ce vraiment la seule solution ? J’avoue que devoir utiliser les « IDs » directement est assez bizarre. D’autant que le country_code est présent dans la DB.


Edit : La création d’une facture est également mystérieuse. En spécifiant « lines » (sous forme d’array, dont chaque valeur est un objet reprenant les élément de lignes décrits dans facture.class.php tels que description, subprice, qty, …) une erreur SQL est retournée. Les logs m’indiquent que l’API comprend bien qu’il y a un array « lines », mais n’en extrait aucune des valeurs spécifiées.