L'API Invoice Ninja est construite sur le Framework Laravel, il s'agit d'un framework PHP extrêmement populaire avec une documentation et des tutoriels de grande qualité, disponibles partout sur le Web. Pour commencer à personnaliser et/ou étendre Invoice Ninja, vous devrez vous familiariser avec la dernière version de Laravel et toutes ses fonctionnalités. L'espace de noms URL pour l'api est /api/v1 Le Portail Client est une application Web traditionnelle également construite avec Laravel ainsi qu'avec des composants Livewire et Tailwind. L'espace de noms URL pour les URL orientées client est /client/
Si vous prévoyez de créer une nouvelle fonctionnalité dans Invoice Ninja, par exemple un module d'inventaire, plutôt que de l'intégrer directement dans la base de code, nous vous recommandons fortement d'utiliser la bibliothèque Laravel Modules. Cette bibliothèque fait déjà partie du noyau d'Invoice Ninja, vous pouvez donc vous lancer directement et commencer à construire.
Si vous prévoyez de contribuer avec votre code au dépôt officiel d'Invoice Ninja, veuillez vous assurer d'avoir une couverture de test pour votre fonctionnalité. Nous utilisons PhpUnit pour nos tests d'API, et Cypress pour nos tests d'interface utilisateur du portail client.
L'application est divisée en trois parties principales : le backend/API et les deux portails d'administration.
Notre définition complète de l'API se trouve ici
L'url de base pour la v5 est :
https://invoicing.co
Invoice Ninja v4 a été initialement construit comme une application web avec une API ajoutée par la suite pour prendre en charge les cas d'utilisation courants et la fonctionnalité limitée de l'application mobile v4. Avec la v5, nous avons plutôt construit une application API-first, toutes les fonctionnalités des applications web/mobile/bureau sont alimentées par l'API.
Par exemple, dans la v4, les inclusions de clients sont limitées aux contacts, factures, crédits et activités, alors que dans la v5, toutes les options sont disponibles. Cela inclut : contacts, documents, gateway_tokens, documents, gateway_tokens, activités, grand livre et journaux système.
Un autre inconvénient majeur de l'API v4 est la documentation, même si les fonctionnalités sont limitées, ce qui est disponible n'est pas nécessairement documenté. Dans la v5, nous nous sommes assurés de documenter chaque aspect de l'API.
Les APIs v4 et v5 sont principalement les mêmes, mais il y a quelques changements clés dont il est important d'être conscient.
Le type de données des champs d'identifiant a été modifié de entier à chaîne de caractères pour prendre en charge le nouveau format d'identifiant.
La route pour téléverser des documents a changé, voici un exemple cURL v5 :
curl -X POST https://invoicing.co/api/v1/invoices/<invoice_id>/upload \\
-H 'Content-Type: multipart/form-data' \\
-H 'X-API-TOKEN: TOKEN' \\
-H 'X-Requested-With: XMLHttpRequest' \\
-F _method=PUT \\
-F 'documents[]=@nomdufichier.png'
Le X-API-SECRET nécessite que vous configuriez une variable .env API_SECRET=" }
Ceci est un en-tête facultatif, et n'est évalué que sur la route /api/v1/login.\n
X-API-SECRET: valeur
Ceci est un en-tête obligatoire.
X-API-TOKEN: valeur
Ceci est un en-tête obligatoire.
X-Requested-With: XMLHttpRequest
Ceci est un en-tête requis lors de l'utilisation des méthodes POST/PUT.
Content-Type: application/json\nContent-Type: multipart/form-data
Dans la version 5 de Invoice Ninja, nous passons des clés primaires basées sur des entiers aux hashed_id's, ce sont des représentations de chaînes de caractères obscurcies de la clé primaire pour tous les enregistrements d'entités.
Want to contribute? Edit this page on GitHub!