sevDesk mit n8n: Polling-Trigger, Grenzen der API

sevDesk lässt sich in n8n nur über den HTTP Request Node anbinden, denn es gibt kein natives sevDesk-Node im n8n-Kern und damit auch keinen Webhook-Trigger, der Änderungen in sevDesk automatisch an einen Workflow meldet. Wer sevDesk-Daten wie neue Rechnungen, Kontakte oder Belege in n8n verarbeiten möchte, baut deshalb einen Polling-Trigger: Ein Schedule Trigger Node ruft in festen Abständen die sevDesk-API per HTTP Request ab und übergibt die Antwort an den restlichen Workflow. Die sevDesk-API selbst begrenzt dabei die Seitengröße pro Abfrage auf maximal 1000 Datensätze pro Aufruf und verlangt seit April 2025 die Authentifizierung über einen Authorization-Header statt über einen URL-Parameter. Stand: Juli 2026.

Warum kein Webhook-Trigger möglich ist

n8n unterscheidet zwischen nativen, im Kern integrierten Nodes und Community-Nodes, die einzeln nachinstalliert werden. Für sevDesk existiert kein natives Node, also auch kein fertiger Trigger-Node, der auf Ereignisse in sevDesk reagiert. In der offiziellen sevDesk-API-Dokumentation ist an keiner Stelle ein Webhook-Mechanismus beschrieben, über den sevDesk aktiv Daten an ein externes System senden würde. Das bedeutet in der Praxis: Ein Workflow erfährt nicht von selbst, dass in sevDesk eine neue Rechnung erstellt oder ein Beleg gebucht wurde. Er muss aktiv nachfragen, und genau das leistet der Polling-Trigger.

Aufbau: Schedule Trigger plus HTTP Request

Der Schedule Trigger Node startet den Workflow in einem festen Intervall, wahlweise über Sekunden, Minuten, Stunden, Tage oder einen eigenen Cron-Ausdruck. Direkt danach folgt ein HTTP Request Node, der die eigentliche Abfrage gegen die sevDesk-API ausführt, zum Beispiel gegen einen Endpunkt wie Invoice oder Contact. Der HTTP Request Node unterstützt dafür generische Authentifizierungsmethoden wie Header Auth, außerdem eingebaute Pagination-Optionen, mit denen sich Parameter wie limit und offset bei jedem Aufruf automatisch hochzählen lassen. Die Antwort landet als JSON im Workflow und kann anschließend gefiltert, transformiert und an die Zielsysteme weitergegeben werden.

Authentifizierung mit dem sevDesk API-Token

Jeder sevDesk-Administrator besitzt ein API-Token, einen hexadezimalen String mit 32 Zeichen, zu finden in den Kontoeinstellungen. Laut der sevDesk-API-Dokumentation zur Authentifizierung hat das Token eine unbegrenzte Lebensdauer und muss im HTTP Request Node als Wert des Authorization-Headers übergeben werden. Wichtig für ältere Workflows: Bis April 2025 ließ sich das Token auch als URL-Parameter mitgeben, sevDesk hat diesen Weg aus Sicherheitsgründen jedoch entfernt. Wer noch eine alte Integration mit Token in der URL betreibt, muss sie auf den Authorization-Header umstellen, sonst schlägt die Authentifizierung fehl.

Pagination und dokumentierte API-Limits

sevDesk paginiert Listenabfragen über die Parameter limit und offset. In den Beispielen der offiziellen Dokumentation liefert eine Abfrage ohne weitere Angaben standardmäßig bis zu 100 Einträge. Laut der sevDesk-Ankündigung zu den neuen Pagination-Limits erzwingt sevDesk seit dem 30. Mai 2025 zusätzlich eine feste Obergrenze: Der limit-Parameter muss eine ganze Zahl zwischen 1 und 1000 sein, andernfalls antwortet die API mit HTTP 400 und dem Hinweis, dass nur Werte in diesem Bereich gültig sind. Vorher ließen sich auch deutlich größere oder sogar beliebige Werte übergeben. Für einen Polling-Workflow bedeutet das: Bei größeren Datenmengen braucht es mehrere Aufrufe mit steigendem offset, im HTTP Request Node lässt sich das über die Pagination-Einstellung „Update a Parameter in Each Request" abbilden. Konkrete Angaben zu Anfragen pro Minute oder Stunde macht die sevDesk-Dokumentation an dieser Stelle nicht, ein grundsätzliches Rate-Limiting ist aber vorhanden und sollte bei der Wahl des Abfrageintervalls berücksichtigt werden.

Intervall wählen und Wartungsaufwand einplanen

Ohne Webhook gibt es keine Echtzeit-Benachrichtigung, jede Verzögerung zwischen zwei Schedule-Läufen ist eine reale Verzögerung in der Verarbeitung. Ein kürzeres Intervall bringt aktuellere Daten, erhöht aber die Zahl der API-Aufrufe und damit das Risiko, an die nicht öffentlich bezifferten Grenzen zu stoßen. Zusätzlich muss der Workflow selbst dafür sorgen, dass bereits verarbeitete Datensätze nicht doppelt verarbeitet werden, etwa indem der Zeitpunkt des letzten erfolgreichen Laufs gespeichert und bei der nächsten Abfrage als Filter genutzt wird. Diese Logik übernimmt bei einem nativen Node oft das Node selbst, bei einer reinen HTTP-Request-Lösung muss sie im Workflow mitgebaut und bei API-Änderungen wie den beiden Breaking Changes aus 2025 auch gepflegt werden. Wer diesen Aufwand nicht selbst tragen will, findet Unterstützung beim Aufbau solcher Integrationen zum Beispiel unter n8n-Automatisierung von NordFlux oder allgemeiner bei Automatisierung.

Häufige Fragen zu sevDesk und n8n

Gibt es einen offiziellen sevDesk-Node für n8n?

Nein, sevDesk ist kein natives Node im n8n-Kern. Die Anbindung erfolgt über den generischen HTTP Request Node gegen die REST-API von sevDesk.

Wie oft sollte der Schedule Trigger die sevDesk-API abfragen?

Das hängt vom Anwendungsfall ab. Für Buchhaltungsprozesse reicht häufig ein Intervall von 15 bis 60 Minuten, für zeitkritische Anwendungsfälle kürzer. Da sevDesk keine öffentlichen Zahlen zu Anfragen pro Minute nennt, empfiehlt sich ein moderates Intervall mit Fehlerbehandlung statt eines sehr kurzen Takts.

Wie viele Datensätze liefert die sevDesk-API pro Abfrage?

Der limit-Parameter erlaubt seit Mai 2025 nur ganzzahlige Werte zwischen 1 und 1000, alles außerhalb dieses Bereichs führt zu einem HTTP-400-Fehler. Größere Datenmengen erfordern mehrere Aufrufe mit steigendem offset.

Funktioniert die alte Authentifizierung über URL-Parameter noch?

Nein. sevDesk hat diesen Mechanismus zum 29. April 2025 abgeschaltet. Das API-Token muss seither im Authorization-Header jeder Anfrage mitgeschickt werden.