Fillo ships a community node package, n8n-nodes-fillo: a trigger that starts a workflow the moment a response lands, an action node that reads forms and responses, and a credential for your workspace API token.
Install the node
Self-hosted n8n: open Settings → Community Nodes → Install, and enter the package name:
n8n-nodes-fillo
This needs the same Node.js version current n8n itself needs (22 or newer) — nothing extra beyond what your n8n install already requires.
n8n Cloud: not available yet. Verified community nodes install from Cloud's in-app catalogue, and this package isn't verified yet — that submission happens after a public release. Until then, on Cloud use the signed webhook path with n8n's built-in Webhook node instead.
Connect your workspace
- In Fillo, open Settings → Connections → n8n and create a token. It starts with
fcli_and carries that project's full form access — treat it like a password. - In n8n, create a Fillo API credential and paste the token.
- Leave the Fillo URL at its default unless you run Fillo on your own domain.
- Test the credential. n8n calls Fillo and shows the workspace the token belongs to.
A coding agent can mint the same token from the terminal instead of the dashboard: fillo tokens create-connector --tool n8n prints an fcli_ token once, ready to paste into that credential.
Deleting the token in Fillo also removes every webhook subscription it created, so revoking access can't leave a workflow firing behind your back.
Fillo Trigger
- Add the Fillo Trigger node to a workflow and select the credential.
- Choose a Form — the dropdown lists the published forms this token can reach.
- Choose which events start the workflow: a new response, an updated response, or both (the default).
- Activate the workflow.
Activating registers a managed subscription with Fillo automatically; deactivating unregisters it again. There's no webhook URL or signing secret to copy by hand — delivery is instant, the same as a live webhook. Each run receives one item whose data is the same payload documented on Webhooks, so answers, formatted, fields[], and files[] can be mapped visually in the rest of the workflow.
Payload mapping
| Fillo value | n8n use |
|---|---|
event | "response.created" or "response.updated" — branch the workflow on it |
response_id | Stable identity for the same living response, including across a later update |
occurrence_id | Unique per delivery event and stable across retries of that event |
answers | Raw values keyed by field id |
formatted | Display strings for the same fields (option labels, not ids) |
fields | Iterate id, label, kind, raw value, and formatted value together |
respondent | Identity, or null — trust it only when verified is true |
files | File references; each url needs the same Fillo credential to fetch |
Duplicate deliveries
Fillo delivery is at least once, so the same event can arrive twice if an earlier acknowledgment was lost. A signed webhook receiver normally dedupes on the X-Fillo-Delivery-Id header, but the Fillo Trigger node hands your workflow the request body only — n8n doesn't expose delivery headers on a trigger's output item. Dedupe on occurrence_id instead: it's unique per delivery event and stable across retries of that event. Keep response_id as the identity you upsert against, since one response can produce both a response.created delivery and a later response.updated delivery.
Fillo action node
| Resource | Operation | What it returns |
|---|---|---|
| Form | Get Many | Published forms this token's project can reach |
| Response | Get Many | Most recent responses first, limit 1–50 |
A form with no responses yet returns one sample response built from its schema, so fields can be mapped before the first real submission arrives.
Files need the credential
files[].url is a protected link — fetching it needs the same Fillo API token the credential already holds. Use an HTTP Request node with the Fillo API credential to download it, rather than handing the URL to a step that can't authenticate.
Use a signed webhook instead
The Fillo Trigger's managed subscription relies on the unguessability of n8n's own webhook URL to stay private — the same trust model as Fillo's Zapier hooks. It doesn't verify a signature, because the signing secret isn't exposed on this connector surface. If a workflow needs to cryptographically verify each request, add a webhook under the form's Webhooks settings instead and receive it with n8n's built-in Webhook node — that path hands you the signing secret and the X-Fillo-Signature header to check against the raw body.
Related
- Webhooks: The signed, header-bearing alternative when a workflow needs HMAC verification.
- Management API: Read accepted responses from a scheduled workflow instead of a trigger.
- Security and boundaries: Keep the workspace token and workflow credentials out of respondent-facing code.