# Integrations

Last updated: 2026-07-12

Web page: https://fillo.so/docs/integrations
Docs overview: https://fillo.so/docs.md
Quickstart: https://fillo.so/docs/embed.md
Agent setup: https://fillo.so/agents.md

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

1. **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.
2. **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.
3. **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

1. **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.
2. **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.
3. **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 settings are managed in the dashboard. Syncing with a publishable key does not change `notifyEmail` or `sendReceipt`.
- Use an integration or webhook when another system must receive every response. Email notifications can be delayed or missed.

## 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](https://fillo.so/docs/webhooks) 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.

## Next steps

- [Webhook implementation](https://fillo.so/docs/webhooks): Copy the verification code and design for retries.
- [Response operations](https://fillo.so/docs/responses): Check delivery, retry failures, and export matching responses.
- [File storage](https://fillo.so/docs/uploads): Connect the provider that receives respondent uploads.