RXJ – AI Workflow Automation Platform

RXJ is a modern AI-native workflow automation platform inspired by tools like n8n, Zapier, and Make.com. It enables users to visually build, automate, and execute workflows using AI models, APIs, messaging systems, productivity tools, webhooks, and realtime execution pipelines.

The platform is designed as a scalable SaaS product with:

• visual workflow automation
• AI-first architecture
• realtime execution monitoring
• secure credential management
• multi-plan subscription system
• usage-based monetization
• onboarding and billing experience
• a public API for running workflows from your own code

---

🚀 Features

🎨 Visual Workflow Builder

• Drag-and-drop workflow editor powered by React Flow
• Dynamic node-based architecture
• Realtime node execution indicators
• Zoom, pan, and edge connection support
• Topological dependency resolution
• Shared execution context between nodes
• Modular execution engine
• Per-node error handling from the node toolbar: On Error (Stop / Continue), Retry On Fail, Execute Once
• Build with AI: describe a workflow, or a change to the one on the canvas, and a model builds it (see "Build with AI")

---

⚡ Workflow Execution Engine

• Branch-aware execution: only connections activated by IF / Switch / Filter / Text Classifier are followed
• Loops that run a sub-flow once per list item
• Per-item execution after list nodes (see below)
• Sub-workflows: one workflow can call another and use its result
• Error handling: Retry On Fail, Continue on error, Error Trigger, Stop and Error
• Wait node: pause a run for a time, until a date, or until its resume URL is called (see "Waiting executions")
• Human approval: AI Agent tools that wait for a person's Approve or Reject, and a Send and Wait for Approval node
• Hosted forms: a Form Trigger with its own public page, multi-step forms with the Form node, and a Wait node that resumes on a form
• Website chat widget: a public Chat Trigger with an embed snippet, a hosted chat page, per-visitor memory and a handoff to a person
• OCR and vision: an Analyze Image / Document node that reads images and PDFs, scanned ones too, with a vision model
• Web Search and Read Web Page nodes, usable as AI Agent tools
• Browser node: a real Chrome reads pages that need JavaScript, takes screenshots, and clicks, types and submits forms
• Audio: Transcribe Audio and Text to Speech nodes, and voice messages from the Telegram and WhatsApp triggers
• Inngest background execution system
• Dynamic time-based execution engine via an automated Background Ticker (* * * * * clock matching system)
• Shared execution context
• Dynamic {{variable}} interpolation using Handlebars, plus n8n-style {{ $json.field }} expressions
• Execution persistence in PostgreSQL
• Realtime execution updates
• Retry handling and failure propagation
• Waiting executions can be cancelled

Waiting executions

The Wait node pauses a run and continues it later. While it is paused nothing runs and no request is held open: the pause is an Inngest step.sleepUntil or step.waitForEvent, and the execution has the status Waiting.

Resume	The run continues
After Time Interval	after an amount of seconds, minutes, hours or days
At Specified Time	at a date and time (ISO, e.g. 2026-12-24T09:00:00Z; no time zone means UTC). A time in the past does not wait
On Webhook Call	when the execution's resume URL is called (GET, POST, PUT or PATCH)
On Form Submitted	when the form at {{execution.formUrl}} is submitted (see "Forms"). The answers are at {{wait.form.<field>}}

• Resume URL. Every execution has its own: <app>/api/webhooks/wait/<executionId>/<token>. The token is an HMAC of the execution id made with ENCRYPTION_KEY, so the URL cannot be guessed and nothing is stored for it. It is available from the first node on as {{execution.resumeUrl}} (or {{ $execution.resumeUrl }}), so a node before the Wait node can send it out, for example as an approval link in an email. Whoever has the URL can continue that one execution, so send it only to who should decide.
• What the call sent is under the Wait node's variable (default wait): {{wait.body}}, {{wait.query}}, {{wait.headers}}, {{wait.method}}, and {{wait.resumedBy}} (webhook, timeout or timer).
• Timeout. On Webhook Call takes an optional timeout and what to do when nobody called in time: Continue the workflow ({{wait.timedOut}} is true) or Fail the workflow. Without a timeout it waits the longest the server allows.
• Longest wait. 7 days, which is the most Inngest's free plan can sleep. Set WAIT_MAX_DAYS on a plan that allows more.
• Cancel. A waiting execution has a Cancel button on its page. It is marked Failed with "Cancelled by the user while it was waiting", the Inngest run is stopped, and the nodes after the Wait node never run. The page also shows when the wait ends and, for On Webhook Call, the resume URL.
• The resume URL answers 409 while the execution is not waiting for a call (it has not reached the Wait node yet, was already resumed, or has finished) and 404 for a wrong token. One URL serves every Wait node of the execution, one call per wait.
• The token is replaced by [REDACTED] in stored node input and output, and "All Workflow Data" webhook responses leave the URL out.
• A link opened by a mail scanner or a link preview counts as a call. For approvals that matter, link to a page or form that sends a POST instead.
• Waiting executions are not removed by the retention cleanup, cannot be run again until they finish or are cancelled, and a Wait node cannot be an AI Agent tool. After a list node the Wait node pauses once for the whole list.

This is the beginning of the README. Read the rest at the original. Read the full README ↗