SeloraX Automation API
The webhook and action API behind the n8n node, with queue-backed retrying delivery.
Events reach n8n workflows reliably rather than best-effort, with correlation-ID logging to trace a delivery and OpenAPI docs so the node and the API cannot drift apart.
The server half of the SeloraX automation integration: an Express and TypeScript API that issues and verifies credentials, registers webhooks, and processes actions for the n8n community node. Webhook delivery runs through a Bull and Redis queue with retry logic, behind rate limiting, CORS, input sanitization, and security headers, with OpenAPI docs and unit, integration, and property-based tests.
This is a client system, shown as an architecture narrative only: no source code, credentials, or user data are exposed.
Problem
An n8n node is only the client half. Something has to authenticate the workflow, register what it wants to hear about, and actually deliver those events, and delivery to somebody else's endpoint fails routinely.
Constraint
A webhook that is dropped silently is worse than one that never fired, because the workflow author has no way to notice. Delivery had to survive a receiver being down without losing the event.
Decision
Put webhook delivery behind a Bull and Redis queue with retry logic rather than firing inline from the request that triggered it, so a slow or failing receiver cannot block the action that produced the event. Credentials are API key and JWT, and every endpoint sits behind rate limiting and input sanitization.
Tradeoff
A queue adds Redis as a hard dependency and makes delivery asynchronous, so a workflow author cannot read success from the triggering response. Accepted because synchronous delivery couples the platform's uptime to every customer endpoint it talks to.
Result
Events reach n8n workflows reliably rather than best-effort, with correlation-ID logging to trace a delivery and OpenAPI docs so the node and the API cannot drift apart.