DocsIntegrations
Integrations
Route each response to Sheets, Notion, Zapier, email, or your own backend.
Choose by the job to be done
Destinations complement the Fillo response record; they do not replace it. Start with the system that owns the next action, then add another destination only when it has a distinct job.
| Need | Use | Why |
|---|---|---|
| A shared operating table | Google Sheets | Append one row per submission for a team workflow. |
| A workspace database | Notion | Append each response to a generated Notion database. |
| No-code automation | Zapier | Trigger Zaps from new or updated Fillo responses. |
| A custom backend | Webhooks | Receive signed JSON and own downstream processing. |
| A lightweight human alert | Submission email | Notify one team address when a response lands. |
| A confirmation for the respondent | Receipt email | Confirm submission at the first answered email field; the message does not echo answers. |
Set up Sheets or Notion
Connect the workspace account
Open Settings → Connections. The Google connection is shared by Drive storage and Google Sheets; Notion has its own connection and needs a page shared with Fillo as the database home.
Enable the destination on one form
Open Form settings → Response destinations. For Sheets, create a new spreadsheet or select an existing spreadsheet; Fillo uses a Responses tab for a new sheet and the first tab of a selected sheet. For Notion, create the form database and optionally choose which answer becomes its title.
Send a real test response
Open the destination from form settings and confirm the row shape before inviting respondents. Keep stable field ids when editing the form; labels can change while response identity remains intact.
- Each submission is first stored in Fillo, then delivered to the enabled sink.
- Delivery status stays attached to the response. After correcting a connection or provider issue, Retry failed selects currently loaded responses with a failure and requeues all destinations on those responses, including delivered ones. A response drawer's Re-send does the same for one response.
- External rows outlive the integration unless you remove them in that provider. Disabling a destination stops new deliveries; it does not erase prior rows.
Sheets and Notion are append-only in v1
An update-in-place response appends a new row or page instead of revising the first one. Delivery is at-least-once, so a retry can also duplicate a row when the provider committed but Fillo could not confirm it. Keep the Fillo response id in downstream views and make automation duplicate-aware.
Connect Zapier
Create a token
In Settings → Connections → Zapier, create a Fillo API token. It is shown once; copy it before closing. Fillo stores only its hash and safe usage metadata.
Connect the Fillo app in Zapier
Paste the token as the Fillo API key, choose the workspace form, and test the response trigger. The versioned Zapier app provides form dropdowns, sample fields, and REST Hook subscription management.
Revoke deliberately
The Connections list also shows CLI tokens. Revoke only the token you mean to rotate; a revoked token stops its Zapier account or CLI session from authenticating.
API tokens are private
Unlike a pk_ publishable key, a Zapier/CLI token carries workspace management authority. Never ship it in browser code or paste it into a form schema.
Use email for lightweight handoff
- Set Submission alert to one valid team address when a human needs a prompt for each response.
- Enable Receipt email when respondents should receive a submission confirmation. Fillo sends it to the first answered email field and does not include their answers, so make the field required when delivery matters.
- These are dashboard-owned operational settings. Public-key code sync preserves them and ignores incoming
notifyEmailandsendReceiptvalues. - Use an integration or webhook when the next step must be machine-reliable; email is a notification surface, not a queue.
Use webhooks for your own backend
Configure a webhook per form when your backend owns the workflow. Fillo signs the raw request body, records attempts, and retries non-2xx responses or timeouts with backoff.
Webhook delivery is at-least-once. Verify the signature, acknowledge quickly, and deduplicate only on X-Fillo-Delivery-Id. Do not use the response id: response.updated reuses the same response id for a new delivery. The webhook guide contains the exact headers, payload, signature code, and retry schedule.
Operate destinations safely
- Scope OAuth connections and tokens to the workspace that owns the forms; all destination configuration is workspace-scoped.
- Test after schema changes, especially when a downstream workflow assumes a particular label or column type.
- Watch delivery state in Responses. Fix authorization or provider errors before retrying, and make downstream writes duplicate-safe.
- Disconnecting an account affects every form that uses it. Inventory enabled forms and historical data access before rotating or removing a connection.