Slack Trigger
input.slack Input v0.1.0 Starts the workflow when a Slack event arrives (Events API). Answers the url_verification challenge and normalizes each event to a flat { text, user, channel, ts, eventType, team, … } shape.
Finding it in the library
Search the builder's node library for Slack 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.
Library capture pending — regenerate with npm run shots:nodes.
Wired up in the builder
Slack 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.
Canvas capture pending — regenerate with npm run shots:nodes.
How it’s configured
The node’s Configure panel as it opens in the builder when you select the step — every setting laid out with real values. Click any field to edit it.
Config capture pending — regenerate with npm run shots:nodes. See the full property reference below.
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.
| Direction | Port | Label | What flows through it |
|---|---|---|---|
| Output | output | Event |
How data flows through it
As a trigger, Slack 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 signingSecret, path. 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
(Slack Trigger) works as well as the exact type id (input.slack).
In the Copilot panel (or any connected AI):
create a workflow that starts with slack trigger and logs the result As a step in a create_chain_workflow call:
{"type":"Slack Trigger","config":{}} Raw MCP call — add this node to a workflow with add_node
curl -s -X POST http://localhost:48170/mcp -H "content-type: application/json" -d '{ "jsonrpc": "2.0", "id": "1", "method": "tools/call", "params": { "name": "add_node", "arguments": { "workflowId": "<id>", "type": "Slack Trigger" } } }' Example input & output
Captured from a real test run of the workflow above — this is what you see in the run data panel after pressing Test workflow.
Input — what the node received
{
"type": "event_callback",
"team_id": "T1",
"event": {
"type": "message",
"text": "hi slack",
"user": "U1",
"channel": "C1",
"ts": "1.2"
}
} Output — what the node produced
{
"eventType": "message",
"text": "hi slack",
"user": "U1",
"channel": "C1",
"ts": "1.2",
"team": "T1",
"message": {
"type": "message",
"text": "hi slack",
"user": "U1",
"channel": "C1",
"ts": "1.2"
}
} Property reference
Every setting, with its type and default — the same fields shown configured in the panel above.
| Property | Type | Default | Description |
|---|---|---|---|
CredentialcredentialId | credential | "" | Use a stored credential for this connection — its fields are filled in at run start. Pick "None" to enter the connection details manually. accepts credential templates: slack-bot |
Signing secretsigningSecret | string | "" | Slack app signing secret — verifies the X-Slack-Signature HMAC on each inbound POST (serve mode). |
Events pathpath | string | "/slack/events" | The local route Slack's Events API POSTs to. |
Event filterevents | json | [] | Only fire for these event types (e.g. ["message", "app_mention"]). Empty = all. |
Ignore botsignoreBots | boolean | true | Skip events produced by bots (bot_id present) so the bot doesn't answer itself. |
Max body (bytes)maxBodyBytes | int | 1048576 | Largest request body this trigger accepts — bigger requests are rejected with 413 before the workflow runs. 0 = unlimited at the trigger (the app-wide FLOWDROME_MAX_BODY_BYTES ceiling, default 32 MB, still applies). |
Rate limit (req/s)rateLimitRps | double | 0 | Per-client-IP sustained request rate for this trigger. 0 = no rate limit (the default). For internet-exposed apps, prefer rate limiting at a fronting reverse proxy (docs/ingress-guards-design.md). |
Rate limit burstrateLimitBurst | int | 0 | How many requests a client may send back-to-back before the per-second rate applies. 0 = automatic (2× the rate). Shown when (showIf === undefined || showIf(c)) && Number(rateLimitRps ?? 0) > 0 |
Related nodes
The rest of the Input group — the same folder you’d scan in the editor’s library.
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.