How the Bot Builder works

This guide explains the Builder as a system: what a bot is made of, what happens when you save, how flows run at runtime, and the limits and safety rails around everything.

The big picture

A Builder bot is a real Discord application that you own, hosted on Styz infrastructure. You create the application on the Discord Developer Portal, hand the Builder its token and application ID, and from that point on the Builder keeps it online, registers its commands, and runs your flows when people interact with it.

Everything the bot does is a flow. A flow is a small program built on a canvas: a trigger that decides when it runs, and a chain of steps (nodes) that decide what it does. A slash command is a flow. A welcome message is a flow. A reaction-role handler is a flow. Complex bots are just more flows.

Anatomy of a bot

PieceWhat it is
BotYour Discord application: token, prefix, avatar, status, connection secrets, and the list of flows.
FlowOne unit of behavior. Has a name, trigger, options, permissions, cooldown, and a graph of steps.
TriggerThe event that starts the flow: a slash command, a member joining, a keyword in chat, a scheduled time, a button click, and 50+ more.
Step (node)One action or decision inside a flow: send a message, add a role, branch on a condition, call an API, run a game.
Variables{user}, {option:name}, {var:key} and friends - live values injected into step fields while the flow runs.
Data storeA persistent key-value database per bot: scores, counters, AFK states, configs - survives restarts.
ConnectionsSaved credentials for external systems (game servers, AI providers) that nodes reference by name. Secrets never live in flow JSON.

The lifecycle of a flow

From canvas to live command
Build on the canvas, save, sync, and the command is live in Discord.
  1. Build. You place steps on the canvas and wire them together. Every step is validated as you configure it; the canvas warns about disconnected nodes and missing branches before you save.
  2. Save. The backend sanitizes every step (stripping anything the schema does not allow), repairs the graph, and runs full validation. Invalid flows are rejected with the specific errors listed, not silently broken - and a flow containing premium steps on a Free plan is rejected outright rather than half-running later.
  3. Sync. Command-triggered flows are registered with Discord as guild slash commands - they appear in your server almost immediately, not after an hour of propagation. Event flows (member joins, reactions, schedules) need no registration; they are live the moment they are saved.
  4. Run. When the trigger fires, the executor walks your step graph from the entry node, substituting variables, calling the Discord API, reading and writing the data store, and following each step's output wire to the next one.
  5. Log. Every run, warning, and error lands in the bot's Logs tab - permission failures, bad configs, rate caps - so you can see exactly what a flow did.

What happens when a flow runs

The executor starts at the trigger node and follows the next wire from step to step. Along the way it builds a live context: who ran it, what they typed or clicked, which server and channel it happened in. Step fields that contain {variables} are resolved against that context on each run, so {args} always holds this run's input, never a stale value.

  • Branches: steps like Condition, If Variable, Random Branch, and Ask Question have two outputs - then and else. Only the matching path runs.
  • Failures: a step that errors does not kill the run. Every node has an amber error output on its bottom edge - wire it to route failures somewhere (a log channel, a fallback message). Unwired, the run just continues down the normal output. The error text itself is available as {var:error}.
  • Timing: most steps complete in milliseconds. Interactive steps (Ask Question, games, polls, giveaways) pause the flow and wait for user input on a timeout. If nobody responds, they follow their timeout path.
  • Action budget: every step counts as one action. A bot that crosses 600 actions per minute gets throttled for the rest of the window - this is what stops a misconfigured loop or a one-minute schedule from rate-limiting your whole bot.

Isolation and hosting

Hosted Builder bots run in a dedicated process (styz-bothost), completely separate from the main Styz bot. A bug or crash in a hosted bot cannot take the main bot - or other customers' bots - offline. Your bot stays online 24/7 without you running anything.

Each bot's data is scoped to that bot. A flow on your bot can never read another customer's data, connections, or secrets - the query layer enforces it, not just the UI. Tokens are stored encrypted at rest.

Plans and limits

PlanPriceHosted botsFlows per botSteps per flowStep types
Free$0155Core steps (messages, roles, moderation, fun)
Starter$6.99/mo3Unlimited25Every step type (AI, HTTP, economy, games, integrations)
Pro$14.99/mo or $119.99/yr10Unlimited25Every step type

Hard platform limits regardless of plan: 25 slash options per command, 25 choices per option, 600 actions per minute per bot, loops capped at 100 iterations and depth 3, Wait steps up to 5 minutes (use the Reminder node for anything longer - it survives restarts), and message/embed sizes are Discord's own limits.

Where to go next