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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
NordFlux construit des employés numériques pour les organisations : des automatisations et des agents KI qui prennent en charge le travail répétitif. Vous gardez le contrôle.
Aperçu de tous les types de déclencheurs n8n : Schedule, Webhook, Polling, Manuel et Chat, avec une recommandation d'utilisation pour chaque scénario.
Shopware 6 n'a pas de node n8n natif. Voici comment connecter les commandes, les clients et le stock via l'Admin API et le HTTP Request Node.
L'expression cron est presque toujours correcte, le fuseau horaire non. Trois cas réels du forum n8n montrent pourquoi les Schedule Triggers se déclenchent au mauvais moment.
Sans nœud natif ni déclencheur webhook, sevDesk ne laisse que l'approche par polling via Schedule Trigger et HTTP Request, avec des limites d'API documentées et une charge de maintenance propre. NordFlux met en place cette connexion pour vous et prend en charge l'exploitation encadrée afin que l'intervalle corresponde à votre volume de données. Lors du premier échange, nous examinons concrètement vos processus sevDesk.
