sevDesk avec n8n : déclencheur par interrogation, limites de l'API

sevDesk ne peut être connecté à n8n que via le noeud HTTP Request, car il n'existe pas de noeud natif sevDesk dans le coeur de n8n et donc pas de déclencheur webhook qui signalerait automatiquement les modifications dans sevDesk à un workflow. Quiconque souhaite traiter dans n8n des données sevDesk telles que de nouvelles factures, contacts ou justificatifs construit donc un déclencheur par interrogation (polling) : un noeud Schedule Trigger appelle l'API sevDesk via HTTP Request à intervalles fixes et transmet la réponse au reste du workflow. L'API sevDesk elle-même limite la taille de page par requête à un maximum de 1000 enregistrements par appel et exige depuis avril 2025 une authentification via un en-tête Authorization au lieu d'un paramètre d'URL. État : juillet 2026.

Pourquoi un déclencheur webhook n'est pas possible

n8n distingue les noeuds natifs intégrés au coeur et les noeuds communautaires, qui sont installés séparément. Il n'existe pas de noeud natif pour sevDesk, et donc pas non plus de noeud déclencheur tout fait qui réagirait aux événements dans sevDesk. Dans la documentation officielle de l'API sevDesk, aucun mécanisme de webhook par lequel sevDesk enverrait activement des données à un système externe n'est décrit. Cela signifie en pratique qu'un workflow n'apprend pas de lui-même qu'une nouvelle facture a été créée ou qu'un justificatif a été comptabilisé dans sevDesk. Il doit interroger activement, et c'est exactement ce que fait le déclencheur par interrogation.

Structure : Schedule Trigger plus HTTP Request

Le Schedule Trigger Node démarre le workflow à intervalle fixe, au choix en secondes, minutes, heures, jours ou via une expression cron personnalisée. Juste après vient un HTTP Request Node, qui exécute la requête proprement dite auprès de l'API sevDesk, par exemple vers un endpoint tel qu'Invoice ou Contact. Le noeud HTTP Request prend en charge à cet effet des méthodes d'authentification génériques telles que Header Auth, ainsi que des options de pagination intégrées permettant d'incrémenter automatiquement des paramètres tels que limit et offset à chaque appel. La réponse arrive sous forme de JSON dans le workflow et peut ensuite être filtrée, transformée et transmise aux systèmes cibles.

Authentification avec le jeton API sevDesk

Chaque administrateur sevDesk possède un jeton API, une chaîne hexadécimale de 32 caractères, que l'on trouve dans les paramètres du compte. Selon la documentation de l'API sevDesk sur l'authentification le jeton a une durée de vie illimitée et doit être transmis dans le noeud HTTP Request comme valeur de l'en-tête Authorization. Important pour les anciens workflows : jusqu'en avril 2025, le jeton pouvait également être transmis en tant que paramètre d'URL, mais sevDesk a supprimé cette méthode pour des raisons de sécurité. Quiconque exploite encore une ancienne intégration avec le jeton dans l'URL doit la faire passer à l'en-tête Authorization, sinon l'authentification échoue.

Pagination et limites d'API documentées

sevDesk pagine les requêtes de liste via les paramètres limit et offset. Dans les exemples de la documentation officielle, une requête sans autre indication renvoie par défaut jusqu'à 100 entrées. Selon l'annonce de sevDesk concernant les nouvelles limites de pagination sevDesk impose en plus depuis le 30 mai 2025 une limite supérieure fixe : le paramètre limit doit être un nombre entier compris entre 1 et 1000, sinon l'API répond par un HTTP 400 avec l'indication que seules les valeurs dans cette plage sont valides. Auparavant, des valeurs nettement plus grandes, voire arbitraires, pouvaient également être transmises. Pour un workflow de polling, cela signifie : pour des volumes de données plus importants, plusieurs appels avec un offset croissant sont nécessaires, ce qui peut être représenté dans le noeud HTTP Request via le paramètre de pagination « Update a Parameter in Each Request ». La documentation sevDesk ne donne pas de chiffres concrets sur les requêtes par minute ou par heure à ce sujet, mais une limitation de débit de base existe et devrait être prise en compte lors du choix de l'intervalle d'interrogation.

Choisir l'intervalle et prévoir l'effort de maintenance

Sans webhook, il n'y a pas de notification en temps réel ; chaque délai entre deux exécutions planifiées est un délai réel dans le traitement. Un intervalle plus court apporte des données plus récentes, mais augmente le nombre d'appels API et donc le risque d'atteindre les limites, qui ne sont pas chiffrées publiquement. De plus, le workflow lui-même doit veiller à ce que les enregistrements déjà traités ne soient pas traités deux fois, par exemple en enregistrant l'heure de la dernière exécution réussie et en l'utilisant comme filtre lors de la requête suivante. Avec un noeud natif, cette logique est souvent prise en charge par le noeud lui-même ; avec une solution purement basée sur HTTP Request, elle doit être intégrée dans le workflow et également maintenue lors de changements d'API, comme les deux changements majeurs (breaking changes) de 2025. Quiconque ne souhaite pas assumer cet effort lui-même trouvera un accompagnement pour la mise en place de telles intégrations, par exemple auprès de l'automatisation n8n de NordFlux ou plus généralement auprès de l'automatisation.

Questions fréquentes sur sevDesk et n8n

Existe-t-il un noeud sevDesk officiel pour n8n ?

Non, sevDesk n'est pas un noeud natif dans le coeur de n8n. La connexion se fait via le noeud générique HTTP Request vers l'API REST de sevDesk.

À quelle fréquence le Schedule Trigger doit-il interroger l'API sevDesk ?

Cela dépend du cas d'usage. Pour les processus comptables, un intervalle de 15 à 60 minutes suffit souvent, plus court pour les cas d'usage sensibles au temps. Comme sevDesk ne communique pas de chiffres publics sur les requêtes par minute, un intervalle modéré avec gestion des erreurs est recommandé plutôt qu'une cadence très courte.

Combien d'enregistrements l'API sevDesk renvoie-t-elle par requête ?

Depuis mai 2025, le paramètre limit n'autorise que des valeurs entières comprises entre 1 et 1000, toute valeur en dehors de cette plage entraîne une erreur HTTP 400. Des volumes de données plus importants nécessitent plusieurs appels avec un offset croissant.

L'ancienne authentification via paramètre d'URL fonctionne-t-elle encore ?

Non. sevDesk a désactivé ce mécanisme au 29 avril 2025. Depuis, le jeton API doit être envoyé dans l'en-tête Authorization de chaque requête.