RawtohRawtoh/Docs
Documentation

Why Rawtoh

What Rawtoh does that Zapier, IFTTT, Node-RED and Streamer.bot do not, and when another tool is the better choice.

Rawtoh is often described as "Zapier for streamers". The comparison is useful for a first glance and wrong in the details, so here is the honest version: where Rawtoh is different, and where one of the others is the right tool.

The short version

Side by side

RawtohZapierIFTTTNode-REDStreamer.bot
Built forLive shows and their crewsBusiness apps (CRM, email, sheets)Consumer devices and appsIoT and home automationOne streamer, one PC
How events arrivePushed over a WebSocket held open by each moduleMostly polling, every 1 to 15 minutes depending on plan; webhooks for some appsPolling, up to an hour on the free planPushed or polled, depends on the nodePushed, from the local process
Event to scriptUnder 10 msSeconds to minutesMinutesMillisecondsMilliseconds
Bursts (a raid, 300 chat lines a second)Queued, every event processed, none droppedEach event is a billed task; rate limits applyNot designed for itHandled in-process, can stall the flowHandled on the PC
Where your logic runsRawtoh servers, in an isolated sandbox per runZapier serversIFTTT serversYour own machineThe streaming PC
Reaches tools on your PC (OBS)Yes, through a local module or a browser tabNoNoYes, same machineYes, same machine
Calls back into the same toolYes, events in and methods out on one connectionSeparate trigger and action appsOne trigger, few actionsYesYes
Logic is written asTypeScript, typed from the modules you installedVisual steps, plus an untyped code stepVisual applets, filter code on paid plansVisual flows, plus function nodesVisual sub-actions, plus C# snippets
Shared code between automationsShared scripts, imported by path——SubflowsReusable actions
Persistent stateKey-value storage per organization, atomic updatesStorage by Zapier, a separate app—Context store, per node, flow or globalGlobal variables
Burst controlThrottle and debounce on any triggerPer-step delay and filters—Delay and rate-limit nodesPer-action cooldowns
A control panel for the crewThe Board: buttons in any browser, each tap attributed to its user—Manual applets on your own phoneDashboard, single userStream Deck plugin, one PC
Team and rolesOrganizations with owner, member and viewerTeam plans—Single instance, shared loginSingle user
Crash isolationPer-run sandbox with memory, stack and time limitsPer taskPer appletOne process: a bad function node stalls the restOne process on the PC
Record of what ranEvery run with its event, logs and each module callTask historyActivity logDebug sidebarLogs on disk
Adding a new integrationAny program that opens a WebSocket, with a TypeScript or Rust SDKZapier developer platformIFTTT developer platform, paidWrite a node in JavaScriptC# plugin
AI assistantThe Companion: reads your explorer and modules, proposes diffs, drives your toolsCopilot that builds ZapsAI applet creation——
Works with the internet downNo, triggers pause until Rawtoh is backNoNoYesYes
Keeps running with the PC offYes, scripts run server-sideYesYesOnly if hosted elsewhereNo

Rawtoh figures are medians measured in production. Figures for the other tools come from their public documentation and plans at the time of writing, and vary by plan.

What is actually different

Pushed, not polled

Each module holds a WebSocket open to Rawtoh and pushes events as they happen. A chat message goes through a persistent queue, a trigger condition and an action, and is back in OBS in tens of milliseconds. Zapier and IFTTT check for new data on a schedule, which is fine for an invoice and useless for a raid.

Bursts are the normal case

A raid or a hype train is hundreds of events in a few seconds. Rawtoh queues every one of them and acknowledges only once your scripts have run; nothing is dropped and nothing is billed per event. Throttle and debounce on the trigger turn fifty gifted subs into one thank-you. On a task-priced service, the same burst is a bill.

The same connection goes both ways

A module emits events and answers method calls over one socket. The OBS module reports a scene change and switches scenes; the Twitch module reports a sub and sends the thank-you; the Board reports a tap and repaints the button. There is no "trigger app" and "action app" split, and OBS on your PC is reachable through a local module that needs no inbound port.

Real code, and that is the point

Visual builders stop where their boxes stop: the moment you need a condition the box does not have, you are out. Rawtoh triggers and actions are TypeScript in a full editor, so there is no ceiling: if you can describe it, you can script it. Event payloads and module methods are typed from the manifests of the modules you installed, so autocompletion knows that a Twitch chat message has is_subscriber and that OBS wants sceneName. Shared scripts hold the code several actions have in common. A quiz with questions, scores, a board and an OBS overlay is three actions and three shared scripts, not fifty nodes.

A crew, not a user

Organizations have owners, members and viewers. The Board is a grid of buttons any of them opens in a browser; every tap is an event that carries who pressed it. Scripts run on Rawtoh, so the show keeps reacting when the streaming PC is busy or the editor is closed.

Each run in its own sandbox

Every execution gets a fresh JavaScript sandbox with memory, stack and time limits. A script that loops forever is stopped and reported; other automations never notice. In Node-RED and Streamer.bot, your code runs inside the tool's own process.

The Companion

An assistant in the sidebar that reads your explorer and your modules, writes and edits scripts as diffs you accept or reject, and can call your tools directly with your own permissions. Zapier and IFTTT have AI that builds a flow from a sentence; none of the four has one that knows the modules you actually connected.

When another tool is the right choice