sevDesk con n8n: disparador de sondeo, límites de la API

sevDesk solo puede conectarse a n8n a través del nodo HTTP Request, ya que no existe ningún nodo nativo de sevDesk en el núcleo de n8n y, por lo tanto, tampoco un disparador webhook que notifique automáticamente los cambios en sevDesk a un flujo de trabajo. Quien desee procesar en n8n datos de sevDesk como nuevas facturas, contactos o comprobantes construye por ello un disparador de sondeo (polling): un nodo Schedule Trigger llama a la API de sevDesk mediante HTTP Request a intervalos fijos y pasa la respuesta al resto del flujo de trabajo. La propia API de sevDesk limita el tamaño de página por consulta a un máximo de 1000 registros por llamada y exige desde abril de 2025 la autenticación mediante una cabecera Authorization en lugar de un parámetro de URL. Estado: julio de 2026.

Por qué no es posible un disparador webhook

n8n distingue entre nodos nativos integrados en el núcleo y nodos de la comunidad, que se instalan por separado. Para sevDesk no existe ningún nodo nativo y, por lo tanto, tampoco un nodo disparador ya preparado que reaccione a eventos en sevDesk. En la documentación oficial de la API de sevDesk no se describe en ningún lugar un mecanismo de webhook mediante el cual sevDesk enviara activamente datos a un sistema externo. En la práctica esto significa: un flujo de trabajo no se entera por sí solo de que se ha creado una nueva factura o se ha contabilizado un comprobante en sevDesk. Tiene que preguntar activamente, y eso es exactamente lo que hace el disparador de sondeo.

Estructura: Schedule Trigger más HTTP Request

El Schedule Trigger Node inicia el flujo de trabajo a un intervalo fijo, ya sea en segundos, minutos, horas, días o mediante una expresión cron personalizada. Justo después viene un HTTP Request Node, que ejecuta la consulta propiamente dicha contra la API de sevDesk, por ejemplo contra un endpoint como Invoice o Contact. El nodo HTTP Request admite para ello métodos de autenticación genéricos como Header Auth, además de opciones de paginación integradas con las que se pueden incrementar automáticamente parámetros como limit y offset en cada llamada. La respuesta llega como JSON al flujo de trabajo y luego se puede filtrar, transformar y pasar a los sistemas de destino.

Autenticación con el token de API de sevDesk

Cada administrador de sevDesk tiene un token de API, una cadena hexadecimal de 32 caracteres, que se encuentra en la configuración de la cuenta. Según la documentación de la API de sevDesk sobre autenticación el token tiene una vida útil ilimitada y debe transmitirse en el nodo HTTP Request como valor de la cabecera Authorization. Importante para flujos de trabajo antiguos: hasta abril de 2025 el token también podía transmitirse como parámetro de URL, pero sevDesk ha eliminado esta vía por motivos de seguridad. Quien todavía tenga una integración antigua con el token en la URL debe cambiarla a la cabecera Authorization, de lo contrario la autenticación fallará.

Paginación y límites documentados de la API

sevDesk pagina las consultas de listas mediante los parámetros limit y offset. En los ejemplos de la documentación oficial, una consulta sin más indicaciones devuelve por defecto hasta 100 entradas. Según el anuncio de sevDesk sobre los nuevos límites de paginación sevDesk impone además desde el 30 de mayo de 2025 un límite superior fijo: el parámetro limit debe ser un número entero entre 1 y 1000, de lo contrario la API responde con HTTP 400 y la indicación de que solo son válidos los valores dentro de ese rango. Antes también se podían pasar valores considerablemente mayores o incluso arbitrarios. Para un flujo de trabajo de sondeo esto significa: para volúmenes de datos mayores se necesitan varias llamadas con un offset creciente, lo cual se puede representar en el nodo HTTP Request mediante el ajuste de paginación "Update a Parameter in Each Request". La documentación de sevDesk no ofrece cifras concretas sobre solicitudes por minuto u hora en este punto, pero existe una limitación de tasa básica que debería tenerse en cuenta al elegir el intervalo de consulta.

Elegir el intervalo y planificar el esfuerzo de mantenimiento

Sin webhook no hay notificación en tiempo real; cada retraso entre dos ejecuciones programadas es un retraso real en el procesamiento. Un intervalo más corto proporciona datos más actuales, pero aumenta el número de llamadas a la API y, con ello, el riesgo de alcanzar los límites, que no están cuantificados públicamente. Además, el propio flujo de trabajo debe asegurarse de que los registros ya procesados no se procesen dos veces, por ejemplo guardando el momento de la última ejecución exitosa y utilizándolo como filtro en la siguiente consulta. Con un nodo nativo, esta lógica suele encargarse el propio nodo; con una solución puramente basada en HTTP Request hay que integrarla en el flujo de trabajo y también mantenerla ante cambios de la API, como los dos cambios importantes (breaking changes) de 2025. Quien no quiera asumir este esfuerzo por sí mismo encontrará apoyo para construir este tipo de integraciones, por ejemplo en automatización n8n de NordFlux o, de forma más general, en automatización.

Preguntas frecuentes sobre sevDesk y n8n

¿Existe un nodo oficial de sevDesk para n8n?

No, sevDesk no es un nodo nativo en el núcleo de n8n. La conexión se realiza mediante el nodo genérico HTTP Request contra la API REST de sevDesk.

¿Con qué frecuencia debería consultar el Schedule Trigger la API de sevDesk?

Eso depende del caso de uso. Para procesos contables suele bastar un intervalo de 15 a 60 minutos, más corto para casos de uso sensibles al tiempo. Dado que sevDesk no publica cifras sobre solicitudes por minuto, se recomienda un intervalo moderado con manejo de errores en lugar de un ciclo muy corto.

¿Cuántos registros devuelve la API de sevDesk por consulta?

Desde mayo de 2025, el parámetro limit solo admite valores enteros entre 1 y 1000; cualquier valor fuera de ese rango provoca un error HTTP 400. Los volúmenes de datos mayores requieren varias llamadas con un offset creciente.

¿Sigue funcionando la antigua autenticación mediante parámetro de URL?

No. sevDesk desactivó este mecanismo el 29 de abril de 2025. Desde entonces, el token de API debe enviarse en la cabecera Authorization de cada solicitud.