sevDesk with n8n: Polling Trigger, API Limits

sevDesk can only be connected to n8n via the HTTP Request node, because there is no native sevDesk node in the n8n core and therefore no webhook trigger that automatically reports changes in sevDesk to a workflow. Anyone who wants to process sevDesk data such as new invoices, contacts or receipts in n8n therefore builds a polling trigger: a Schedule Trigger node calls the sevDesk API via HTTP Request at fixed intervals and passes the response on to the rest of the workflow. The sevDesk API itself limits the page size per query to a maximum of 1000 records per call and has required authentication via an Authorization header instead of a URL parameter since April 2025. As of: July 2026.

Why a webhook trigger is not possible

n8n distinguishes between native nodes integrated into the core and community nodes, which are installed separately. There is no native node for sevDesk, and therefore no ready-made trigger node that reacts to events in sevDesk. Nowhere in the official sevDesk API documentation is a webhook mechanism described through which sevDesk would actively send data to an external system. In practice this means: a workflow does not find out on its own that a new invoice was created or a receipt was booked in sevDesk. It has to actively ask, and that is exactly what the polling trigger does.

Structure: Schedule Trigger plus HTTP Request

The Schedule Trigger Node starts the workflow at a fixed interval, either in seconds, minutes, hours, days, or via a custom cron expression. Right after that comes an HTTP Request Node, which performs the actual query against the sevDesk API, for example against an endpoint such as Invoice or Contact. The HTTP Request node supports generic authentication methods such as Header Auth for this, as well as built-in pagination options that automatically increment parameters such as limit and offset with each call. The response arrives as JSON in the workflow and can then be filtered, transformed and passed on to the target systems.

Authentication with the sevDesk API token

Every sevDesk administrator has an API token, a hexadecimal string with 32 characters, found in the account settings. According to the sevDesk API documentation on authentication the token has an unlimited lifetime and must be passed in the HTTP Request node as the value of the Authorization header. Important for older workflows: until April 2025 the token could also be passed as a URL parameter, but sevDesk has removed this method for security reasons. Anyone still running an old integration with the token in the URL must switch it to the Authorization header, otherwise authentication will fail.

Pagination and documented API limits

sevDesk paginates list queries via the limit and offset parameters. In the examples in the official documentation, a query without further specifications returns up to 100 entries by default. According to the sevDesk announcement on the new pagination limits sevDesk has additionally enforced a fixed upper limit since May 30, 2025: the limit parameter must be an integer between 1 and 1000, otherwise the API responds with HTTP 400 and a note that only values in this range are valid. Before that, significantly larger or even arbitrary values could also be passed. For a polling workflow this means: for larger data volumes, several calls with an increasing offset are needed, which can be mapped in the HTTP Request node via the pagination setting "Update a Parameter in Each Request". The sevDesk documentation does not give concrete figures on requests per minute or hour at this point, but a basic rate limiting is in place and should be taken into account when choosing the polling interval.

Choosing an interval and planning maintenance effort

Without a webhook there is no real-time notification, every delay between two schedule runs is a real delay in processing. A shorter interval brings more up-to-date data but increases the number of API calls and thus the risk of hitting the limits, which are not publicly quantified. In addition, the workflow itself must ensure that already processed records are not processed twice, for example by storing the time of the last successful run and using it as a filter in the next query. With a native node this logic is often handled by the node itself; with a pure HTTP Request solution it must be built into the workflow and also maintained when the API changes, such as the two breaking changes from 2025. Anyone who does not want to bear this effort themselves can find support in building such integrations, for example at NordFlux n8n automation or more generally at automation.

Frequently asked questions about sevDesk and n8n

Is there an official sevDesk node for n8n?

No, sevDesk is not a native node in the n8n core. The connection is made via the generic HTTP Request node against the sevDesk REST API.

How often should the Schedule Trigger query the sevDesk API?

That depends on the use case. For accounting processes, an interval of 15 to 60 minutes is often sufficient, shorter for time-critical use cases. Since sevDesk does not publish figures for requests per minute, a moderate interval with error handling is recommended instead of a very short cycle.

How many records does the sevDesk API return per query?

Since May 2025, the limit parameter only allows integer values between 1 and 1000; anything outside this range results in an HTTP 400 error. Larger data volumes require several calls with an increasing offset.

Does the old authentication via URL parameter still work?

No. sevDesk disabled this mechanism as of April 29, 2025. Since then the API token must be sent with every request in the Authorization header.