Discord Trigger

Starts the workflow when a Discord message arrives — via the Gateway WebSocket (real-time messages) or an interactions endpoint (slash commands). Normalizes each event to a flat { content, authorId, authorName, channelId, guildId, … } shape.

Finding it in the library

Search the builder's node library for Discord Trigger (it lives under Input). A single click opens the in-editor docs panel shown here — description, ports, and every property, without leaving the canvas. Double-click (or drag) to add it to the workflow.

Wired up in the builder

Discord Trigger in a real, runnable flow — captured live from the Studio editor, exactly as it looks on your canvas. This is the same workflow used for the example input & output below.

How it’s configured

The node’s settings as the builder shows them — every field laid out with real values. In the Studio these are edited on the node: click the chevron on the divider under its ports to open them.

Ports

This is a trigger — it starts runs and takes no input wire.

Ports are the node’s contract with its neighbours. In the editor a port label renders bold when wired and italic when optional; ◈ ports accept attachment carriers rather than data wires.

How data flows through it

As a trigger, Discord Trigger starts runs — it takes no input wire. What it emits is the request wrapper: the event’s body becomes the payload, and the wrapper carries the event metadata around it (for an HTTP-style trigger that’s headers.*, request.method, request.path and query). Downstream nodes consume the content — the wrapper is unwrapped at each node boundary, and expression roots like {{ headers.x }} still resolve against the wrapper when you need the metadata. See Runs & run data for the envelope model.

Expressions in the config

String-typed properties accept {{ }} expressions evaluated against the incoming item at run time — e.g. {{ $json.customer.email }}. On this node that’s token, publicKey, path, baseUrl. JSON- and code-typed fields never interpolate — they are passed through literally.

Build it with AI

Every node in this reference is reachable through Flowdrome’s AI Copilot and the MCP tools — say what you want, and the graph surgery happens server-side. Node types resolve fuzzily, so the catalog label (Discord Trigger) works as well as the exact type id (input.discord).

In the Copilot panel (or any connected AI):

create a workflow that starts with discord trigger and logs the result

As a step in a create_chain_workflow call:

{"type":"Discord Trigger","config":{}}

curl -s -X POST http://localhost:4800/mcp -H "content-type: application/json" -d '{ "jsonrpc": "2.0", "id": "1", "method": "tools/call", "params": { "name": "add_node", "arguments": { "workflowId": "<id>", "type": "Discord Trigger" } } }'

Example input & output

Captured from a real test run of the workflow above — this is what the Runs view shows after pressing Test workflow.

Input — what the node received

Output — what the node produced

Property reference

Every setting, with its type and default — the same fields shown configured above.

Related nodes

The rest of the Input group — the same folder you’d scan in the editor’s library.

• HTTP Trigger Serves HTTP endpoints and starts the workflow with the request
• Telegram Trigger Starts the workflow for every Telegram bot update — long-polls getUpdates (default) or serves a secret-token-v
• WhatsApp Trigger Starts the workflow when a WhatsApp message arrives (Meta Cloud API webhook)
• Slack Trigger Starts the workflow when a Slack event arrives (Events API)
• WebSocket Trigger Accepts a persistent WebSocket connection; each inbound message starts the workflow, and data sent to its feed
• Inject Injects static manual test payloads as workflow input.
• Manual Trigger Starts the workflow when run manually, passing your run/test data forward (empty item by default).
• Schedule Fires on a cron schedule or fixed interval, emitting a tick with the fire time.

This page is generated from the node registry by gen-node-docs.mjs on every site build — ports, properties, defaults and visibility rules cannot drift from the code. The screenshots and example data are captured from a live Flowdrome by npm run shots:nodes and npm run gen:examples.