Start an n8n workflow from each accepted Fillo response, for example to queue a review, create a project, or notify the person doing the work. Import a tested review queue, or build the workflow yourself.

Set up once

Install n8n-nodes-fillo on a self-hosted n8n that allows community packages.
In Fillo, create a token under Settings > Connections > n8n.
In n8n, add a Fillo API credential with that token.
Publish your intake form and confirm one response in Fillo.

The n8n integration reference covers installation and every trigger and action operation. For the form itself, use the client intake guide. Keep the token in n8n, never in browser code or workflow exports.

Import the review queue

Download the workflow JSON and its Postgres setup SQL. The export has no credentials, pinned executions, or live form IDs.

Tested with	Version
n8n	2.40.5
`n8n-nodes-fillo`	0.1.0
Postgres	18

Run the setup SQL once in your destination database.
Import the workflow JSON.
In Fillo Trigger, select your Fillo API credential and the published form.
In Save intake atomically, select your Postgres credential.
Publish the workflow and submit one fictional response.
Check for one new row in fillo_intake.review_queue.

Connect n8n with a database role limited to the fillo_intake schema, its two tables, and accept_response. Don't use an administrator role.

Queue behavior	Detail
Events	Both Response Created and Response Updated are on
One row per response	Keyed by form ID and `response_id`
`review_status`	Starts as `new`. A response edit keeps your team's value.
Edits	A newer `updated_at` replaces the answers. Older or equal ones are ignored.
Duplicates	`processed_occurrences` records each `occurrence_id` once
Database retries	The Postgres node tries up to three times
Execution data	Failed runs are kept and can contain answers. Successful runs aren't.

The export stops at the queue. It doesn't send notifications, create projects, or download files. Give any extra step its own duplicate handling.

Recover a failed write

The trigger acknowledges each delivery before the database write, so Fillo won't resend after a database failure.

Turn on failure monitoring for the workflow.
Fix the destination.
Retry the failed execution in n8n.

The write runs in one transaction, so a failed attempt never marks its occurrence_id as processed. Set execution pruning and database retention to suit what you collect.

Build the workflow yourself

Add Fillo Trigger and select the credential and the published form.
Choose Response Created, and Response Updated if edits matter.
Listen for a test event, then submit a response.
Inspect response_id, occurrence_id, event, answers, and files.
Add an Edit Fields (Set) node and map answers to your destination.
Upsert the destination record by response_id.

Answer shapes depend on the field kind, so map from a real output. A sample response helps you map fields. It doesn't prove a live delivery worked.

Handle duplicate deliveries

Fillo delivers at least once. The same event can arrive twice.

Key	Stable across
`occurrence_id`	Retries of one delivery event
`response_id`	The response's created and updated events

Use your destination's idempotency key or a unique constraint on response_id. Record each processed occurrence_id only after the downstream work succeeds. Check event before you send a new-submission notification.

Why not deduplicate on a header or a lookup

A "look up, then insert" check can race when two executions run at once. The trigger also passes the request body only, not delivery headers. If you need to verify each request cryptographically, use the signed webhook path and check the raw body first.

Fetch uploaded files

files[].url is protected. Download it with an HTTP Request node that uses the Fillo API credential. Forwarding the URL to another service doesn't grant access.

The original file stays in your connected storage. n8n's execution data is a separate copy with its own retention.

Prove the workflow before you rely on it

Submit one response and find exactly one destination record.
Replay its delivery and confirm nothing duplicates.
Edit the response and confirm the same record updates, if updates are on.
Break a test destination credential, then restore it and retry in n8n.
Before sharing an export, remove credentials, pinned data, emails, and file URLs.

Support intake example: Try an intake flow before you connect a destination.
n8n integration: Install the node and map the full payload.
Delivery health and replay: Find and replay a failed delivery.
Webhooks: Verify signed requests when a workflow needs it.

Route client intake through n8n