Automatiser Lexoffice via n8n : pas de node natif, mais une intégration API complète pour les justificatifs, les factures et les contacts.
Lexoffice peut être automatisé avec n8n, bien qu'il n'existe pas de node n8n officiel pour Lexoffice : la solution est le node HTTP Request, qui communique directement avec l'API publique de Lexoffice et y récupère des justificatifs, crée des factures ou synchronise des contacts. Pour cela, il faut une clé API personnelle du compte Lexoffice, que n8n transmet comme jeton bearer dans l'en-tête Authorization, ainsi qu'une credential Header Auth enregistrée dans le node HTTP Request. L'API de production fonctionne depuis mai 2025 sous le domaine api.lexware.io et est limitée à un maximum de deux requêtes par seconde. État : juillet 2026.
Lexoffice ne fait pas partie des services officiellement intégrés par n8n, c'est pourquoi les workflows doivent utiliser le node HTTP Request générique au lieu d'un node Lexoffice tout prêt. Pour de tels cas, n8n prend en charge plusieurs méthodes d'authentification génériques dans le node HTTP Request, dont Header Auth, Basic Auth, OAuth2 et Query Auth (documentation n8n sur le node HTTP Request). Pour Lexoffice, Header Auth est le choix approprié, car l'API exige une authentification par jeton bearer via l'en-tête Authorization. Le prix de cette flexibilité : les endpoints, les champs et la gestion des erreurs doivent être reconstruits manuellement, et en cas de modification de l'API par Lexoffice, le workflow doit être maintenu de manière autonome au lieu de fonctionner automatiquement avec une mise à jour du node.
L'authentification se fait via une clé API personnelle, que vous générez dans le compte Lexoffice sous les paramètres de l'API publique et que vous transmettez comme jeton bearer dans l'en-tête Authorization de chaque requête (documentation de l'API Lexware). Dans n8n, vous créez pour cela dans le node HTTP Request une credential Header Auth nommée Authorization avec la valeur Bearer suivie de la clé. Deux points techniques sont importants pour la planification du workflow :
Les nouveaux justificatifs peuvent être récupérés via le endpoint GET /v1/voucherlist, qui peut être filtré par paramètres de requête selon le type de justificatif, le statut et la date de création ou de modification. Dans n8n, vous configurez le node HTTP Request avec la méthode GET et l'URL https://api.lexware.io/v1/voucherlist, complétée par des paramètres comme voucherType, voucherStatus et createdDateFrom, par exemple pour ne récupérer que les factures ouvertes des dernières 24 heures. La réponse est paginée, avec une taille par défaut de 25 entrées par page et des champs comme totalPages et totalElements, c'est pourquoi une synchronisation complète nécessite une boucle de pagination. Un modèle typique : un trigger cron démarre le workflow toutes les heures, récupère les justificatifs nouveaux ou modifiés et les écrit dans un tableau ou un tableau de bord interne.
De nouvelles factures sont créées via une requête POST vers /v1/invoices, où le corps JSON contient le client, les lignes de facture et les taux de TVA. Dans le node HTTP Request, vous sélectionnez la méthode POST, définissez le Content-Type sur application/json et transmettez le corps de la facture soit à partir de données de workflow précédentes, soit à partir d'un node Set qui assemble les champs conformément au schéma Lexoffice. Un exemple pratique : la finalisation d'une commande dans une boutique en ligne déclenche via webhook un workflow n8n qui transfère automatiquement les données client et les lignes dans le format attendu par Lexoffice et crée la facture. L'API valide le schéma de manière stricte, c'est pourquoi des tests avec de vraies données de test sont recommandés avant qu'un tel workflow ne soit mis en production.
Les contacts peuvent être interrogés via GET /v1/contacts avec des filtres comme l'e-mail ou le nom et créés via POST /v1/contacts, ce qui permet une synchronisation entre Lexoffice et un CRM ou un tableau. Un modèle courant vérifie via GET si un contact avec une adresse e-mail donnée existe déjà, et ne le crée via POST qu'en cas de besoin, afin d'éviter les doublons. Pour les entreprises qui utilisent Lexoffice comme comptabilité à côté d'un CRM séparé, cela évite la double maintenance manuelle des données de contact. Ceux qui souhaitent exploiter durablement de tels workflows en plusieurs étapes avec gestion des erreurs, contrôle des limites de débit et monitoring trouveront chez NordFlux un accompagnement pour la mise en place de workflows n8n, y compris l'évaluation des processus qui valent réellement la peine sur le plan technique et économique.
Non, n8n ne propose pas de node officiel et natif pour Lexoffice, c'est pourquoi la connexion passe par le node HTTP Request générique contre l'API publique de Lexoffice. Cela signifie plus d'efforts de configuration qu'avec un node tout prêt, mais techniquement toutes les fonctions essentielles comme les justificatifs, les factures et les contacts sont accessibles via l'API. Avec une credential Header Auth configurée une seule fois, un nombre illimité d'étapes de workflow peut s'appuyer sur le même accès.
L'API Lexoffice limite les requêtes à un maximum de deux requêtes par seconde ; en cas de dépassement, elle répond avec le code de statut HTTP 429. Dans les workflows n8n comportant de nombreux enregistrements, vous devriez donc intégrer un node Wait ou une boucle limitée afin de ne pas dépasser la limite. Pour les synchronisations plus importantes, par exemple plusieurs centaines de contacts, cela se remarque dans la durée d'exécution et doit être pris en compte lors de la planification du workflow.
Depuis le 26 mai 2025, l'API Lexoffice de production fonctionne sous le domaine api.lexware.io, l'ancienne adresse sous lexoffice.io a depuis été remplacée. Les workflows n8n qui utilisent encore l'ancienne URL devraient être basculés vers la nouvelle URL de base afin d'éviter des erreurs. La clé API elle-même n'est pas affectée et continue d'être gérée dans le compte Lexoffice.
Comme la connexion repose sur des requêtes HTTP construites soi-même plutôt que sur un node n8n maintenu, le workflow doit être adapté manuellement en cas de modification du schéma ou des endpoints. C'est le prix de la flexibilité d'un modèle individuel : il n'existe pas de mécanisme de mise à jour automatique comme en aurait un node officiellement maintenu. Ceux qui ne veulent pas assumer eux-mêmes cet effort de maintenance devraient le prendre en compte fermement dès la planification.
Fondateur de NordFlux. Sept ans d'expérience, du web et du SEO jusqu'à l'automatisation à l'échelle d'un groupe, aujourd'hui pragmatique pour les PME et avec une souveraineté des données allemande.
Certifications
sevDesk n'a pas de noeud n8n natif : voici comment construire un déclencheur par interrogation avec les noeuds Schedule Trigger et HTTP Request, limites d'API documentées incluses.
Obligation de facturation électronique 2025-2028 expliquée clairement : ZUGFeRD vs. XRechnung et comment n8n traite automatiquement les factures électroniques entrantes.
Comparaison des nodes n8n pour l'automatisation CRM : périmètre fonctionnel de HubSpot, Pipedrive et Zoho CRM, ainsi que des workflows typiques.
La connexion via le nœud HTTP Request est techniquement réalisable, mais l'authentification, la gestion des erreurs et la synchronisation des justificatifs, factures et contacts demandent une configuration soignée. NordFlux conçoit et exploite cette intégration Lexoffice pour qu'elle reste fiable au-delà du premier test. Lors d'un premier échange, nous précisons quels processus vous souhaitez automatiser.
