API REST Adliss : documentation pour intégrateurs

Mis à jour le 22/09/2026 · Adliss

Pour vous connecter à l'API Adliss, appelez https://api.adliss.fr avec un jeton, le tenant et l'entité concernés. Envoyez les en-têtes d'authentification et de contexte sur chaque appel, y compris en GET. Les réponses utilisent le format JSON.

Obtenir un accès

Chaque client Adliss est un tenant, identifié par son compte, par exemple NESS. Un tenant possède une ou plusieurs entités, qui correspondent aux sociétés. Chaque appel s'exécute dans le contexte d'un tenant et d'une entité.

Le jeton de compte, aussi appelé jeton d'intégration, est propre à un tenant. L'équipe Adliss le remet sur demande et il n'a pas de date d'expiration. Utilisez ce jeton pour un connecteur de site e-commerce ou un automate.

Le jeton utilisateur est émis automatiquement à chaque connexion d'un utilisateur dont l'administrateur du tenant a activé l'option « accès externe ». Il est valable 30 jours. Ses droits découlent du rôle de l'utilisateur dans Adliss. Il est visible et révocable dans la rubrique « Jetons API » de sa fiche profil.

La création autonome d'un jeton n'est pas proposée. Demandez l'accès à l'équipe Adliss par le contact du site. Pour un jeton utilisateur, l'administrateur du compte active l'option « accès externe ».

Les droits sont appliqués par ressource : customers:read, customers:create, customers:update, orders:read, orders:create, orders:update, invoices:read, entities:read, users:read et shop-config:read. Un appel hors de ces droits renvoie 403 FORBIDDEN.

Adresse, en-têtes et format

L'adresse de production est https://api.adliss.fr. Le contrôle GET https://api.adliss.fr/health répond :

{"success":true,"data":{"status":"ok","service":"adliss-api-gateway","version":"v1",…}}

Le contrôle GET /{tenant}/health répond de même avec le nom du tenant. Sur tous les appels, envoyez Authorization: Bearer <jeton>, X-Tenant: <tenant> et Accept: application/json. Le tenant figure aussi dans l'URL et les deux indications sont requises. Avec un jeton de compte, ajoutez obligatoirement X-Entity-Id: <id d'entité>.

Pour POST, PUT et PATCH, envoyez un corps JSON et Content-Type: application/json. Un JSON invalide renvoie 400 INVALID_JSON. Un autre type de contenu renvoie 415 UNSUPPORTED_MEDIA_TYPE.

Les routes suivent les formats /{tenant}/v1/{ressource} et /{tenant}/v1/{ressource}/{id}. GET sert la liste, POST la création, GET /{id} le détail, et PUT ou PATCH /{id} la mise à jour. Voici un appel réel :

curl https://api.adliss.fr/NESS/v1/entities \
  -H "Authorization: Bearer <jeton>" \
  -H "X-Tenant: NESS" \
  -H "X-Entity-Id: 1" \
  -H "Accept: application/json"

La réponse réelle est :

{"success":true,"data":[{"id":1,"name":"LOCK NESS Informatique","company_Name":"LOCK NESS Informatique"}]}

Consultez aussi la page API et intégrations.

Les ressources

Ressource	Route	Verbes	Ce qu'elle porte
Entités	/v1/entities	GET	Les sociétés du compte : id, name, company_Name
Utilisateurs	/v1/users	GET (filtre entity_id optionnel)	id, entity_id, name, email
Clients	/v1/customers	GET, POST, GET /{id}, PUT ou PATCH /{id}	Fiche client : company, surname, firstname, email, tel, address, zip, city, siret, siren, tva_intra, actif ; le détail renvoie aussi l'adresse de livraison (delivery)
Commandes	/v1/orders	POST, GET /{id}, PUT ou PATCH /{id}	Création avec customer_id et items[] (obligatoires), source (défaut SHOP), status (défaut BC) ; le détail renvoie bill et payments[] (id, debit, credit, number, info, day_payment)
Factures	/v1/invoices	GET, GET /{id} (lecture seule)	Liste filtrable par status, customer_id, avec limit (défaut 50, maximum 200) et offset ; chaque ligne : id, title, status, num_order_customer, customer_id, customer_name, entity_id, shop, created_at, updated_at. Le détail renvoie bill, items[], payments[], total_ht, total_ttc, total_tva
Produits	/v1/products	GET, POST, GET /{id}, PUT ou PATCH /{id}	Catalogue publié sur la boutique ; la liste renvoie products[] et un objet pagination (total, start, length) ; champs de création : ref, libelle, price_sold, taux_tva, CodeEAN, actif
Configuration boutique	/v1/shop-config	GET	Paramètres du site marchand connecté
Pages CMS	/v1/shop-pages/{id}	GET	Une page éditoriale par identifiant
Blog	/v1/blogs, /v1/blogs-md	GET, GET /{id ou slug}	Articles HTML, et articles Markdown (corps renvoyé sur le détail seulement)

Voici la réponse réelle de GET /NESS/v1/invoices?limit=2 :

{"success":true,"data":[{"id":10590,"title":null,"status":"D","num_order_customer":null,"customer_id":1,"customer_name":"ABP MANUTENTION","entity_id":1,"shop":null,"created_at":"2026-09-07 14:17:06","updated_at":"2026-09-15 18:41:51"},{"id":10589,"title":null,"status":"F","num_order_customer":null,"customer_id":104,"customer_name":"ABP MANUTENTION","entity_id":1,"shop":null,"created_at":"2026-09-07 13:28:23","updated_at":"2026-09-18 11:23:23"}]}

Les statuts sont D pour devis, F pour facture et BC pour commande. Les montants sont renvoyés en euros, sous forme décimale avec deux chiffres, et non en centimes.

Réponses et erreurs

Une réponse réussie suit cette enveloppe :

{"success":true,"data":…}

Une erreur suit cette enveloppe :

{"success":false,"error":{"code":"…","detail":"…","status":<code HTTP>}}

Sans jeton, la réponse réelle est :

{"success":false,"error":{"code":"UNAUTHORIZED","detail":"Missing auth headers: X-Tenant, Authorization: Bearer <token>","status":401}}

Une erreur métier réelle répond :

{"success":false,"error":{"code":"BUSINESS_ERROR","detail":"customer introuvable","status":422}}

Les autres codes sont INVALID_ACTION 400, INVALID_RESOURCE 400, ACTION_NOT_FOUND 404, NOT_FOUND 404, METHOD_NOT_ALLOWED 405 et INTERNAL_ERROR 500. Les codes INVALID_JSON 400, UNAUTHORIZED 401, FORBIDDEN 403, UNSUPPORTED_MEDIA_TYPE 415 et BUSINESS_ERROR 422 correspondent aussi aux cas décrits dans cette page.

Les appels depuis un navigateur sont acceptés pour les origines déclarées par le compte. Chaque tenant possède sa liste d'origines autorisées, dans le cadre de sa sécurité et conformité.

Recevoir des événements : les webhooks entrants

Adliss reçoit quatre types d'événements. Stripe transmet les encaissements en ligne. La signature Stripe est vérifiée et un paiement validé crée le règlement sur la facture. JeFacture / Banqup, plateforme agréée n° 0055, transmet les statuts des factures électroniques émises et reçues avec vérification de la signature HMAC.

Mailjet transmet les retours d'e-mails : rebond, blocage et plainte. Ces informations sont reportées sur l'envoi et sur le prospect. AllMySMS transmet les accusés de réception des SMS.

L'équipe Adliss configure ces quatre connecteurs avec le client et conserve les secrets côté serveur. Ils ne demandent aucun développement au client. Des modules WordPress/WooCommerce, PrestaShop 1.7 et Shopify, qui consomment cette API, sont aussi fournis.

Le serveur MCP pour les agents IA

Le serveur se trouve à l'adresse https://mcp.adliss.fr. Il utilise le protocole MCP, Model Context Protocol. Il est utilisable par Claude sur claude.ai, ChatGPT et tout client MCP.

Son authentification utilise OAuth 2.1 avec PKCE, méthode S256. La découverte passe par /.well-known/oauth-authorization-server. Les flux sont authorization_code et refresh_token. L'enregistrement dynamique d'un client est soumis à une liste blanche côté Adliss.

L'utilisateur se connecte avec son identifiant au format login#TENANT, son mot de passe Adliss, puis choisit son entité. Le jeton d'accès est valable 8 heures et le jeton de rafraîchissement 30 jours. Les droits sont mcp, mcp:tools et offline_access.

Le serveur propose 56 outils. Ils couvrent search et fetch, les entités et utilisateurs, ainsi que la liste, la recherche, la fiche, la création ou la mise à jour des clients. Ils couvrent la liste, la fiche, la création et la mise à jour des produits ; la liste, la recherche et la fiche des fournisseurs ; puis les factures et devis avec liste, fiche, création, mise à jour, lignes, règlements, finalisation, PDF et envoi.

Les outils couvrent aussi les factures fournisseurs avec leur liste, leur fiche et leur échéance. Le planning et les articles de blog Markdown disposent d'outils de liste, fiche, création, mise à jour et suppression. L'exploration du schéma et les requêtes de lecture passent par adliss_explore, adliss_schema et adliss_codex_query, avec des requêtes SELECT seulement.

Le serveur MCP accepte 60 requêtes par minute et par jeton. Au-delà, il répond 429 avec Retry-After. Les écritures sur les documents commerciaux suivent les mêmes règles que l'interface : piste d'audit et finalisation explicite d'une facture. Les outils de requête restent en lecture seule.

Ce que l'API ne fait pas encore

• La création autonome de jeton n'est pas disponible : l'accès est ouvert par l'équipe Adliss ou par l'administrateur du compte.
• L'API ne propose pas DELETE sur les clients, produits, commandes et factures. Une facture finalisée ne se supprime pas : elle s'annule par avoir dans Adliss.
• La pagination limit/offset n'existe que sur les factures. Les autres listes renvoient l'ensemble ; les produits renvoient leur propre objet pagination.
• Il n'existe pas de ressource REST pour les documents GED, les stocks, le planning ni les règlements isolés. Le planning et les règlements de facture sont accessibles par le serveur MCP ; ces objets sont aussi accessibles dans l'interface.
• Adliss ne notifie pas encore un système tiers d'un événement. Vous devez interroger l'API.
• Il n'existe pas d'environnement de test public séparé. Les essais se font sur le compte d'essai gratuit du client.
• L'API REST ne comporte pas de limitation de débit à ce jour. Un usage raisonnable est attendu ; une limitation pourra être introduite avec préavis.

Adliss est proposé à partir de 49 € HT par mois, avec 3 utilisateurs inclus ; chaque utilisateur supplémentaire coûte 35 € par mois. L'API et le serveur MCP sont inclus, sans option payante. L'hébergement est en France. L'essai se fait sans carte bancaire et sans engagement. Une équipe en France répond au 09 72 16 45 14.

Questions fréquentes