*REST API › Guides*

# Zapier, Make and n8n

> Zapier, Make and n8n can all call the Filmo API with their generic HTTP step. Send the key as a bearer header, page through lists with the cursor, wait when you get a 429 and give every write its own idempotency key.

## Before you build

- Create one key per scenario or Zap, with only the scopes it needs (see [Scopes](https://docs.filmo.io/rest-api/guides/scopes)).
- Store the key in the platform's credential or secret storage. Do not paste it into a field of the scenario that is shown in logs or exported with it.
- Make your first call to [`GET /api/v1/account`](https://docs.filmo.io/rest-api/endpoint-reference/account/get-the-account) to confirm the key works and to see its scopes.

## Set up the HTTP step

In Zapier use a custom HTTP request action. In Make use the HTTP module. In n8n use the HTTP Request node. The settings are the same in all three.

| Setting | Value |
| --- | --- |
| URL | `https://app.filmo.io/api/v1/...`, with the path of the operation |
| Method | The method of the operation (GET to read, POST, PATCH or PUT to write) |
| `Authorization` header | `Bearer ` followed by the key, taken from the credential store |
| `Accept` header | `application/json` |
| `Content-Type` header | `application/json` on writes |
| Body | JSON. Dates are ISO 8601 with an offset, such as `2026-10-17T09:00:00+02:00` |
| `Idempotency-Key` header | On every write; see below |

Let the step hand 4xx and 5xx responses to your scenario instead of failing silently, so you can read the status, the `code` of the error and `Retry-After`. Branch on `code`, never on `detail`.

## Page through lists

1. **Request the first page** Send the list request with a `limit` (the maximum is 500).
2. **Check for more** Read `pagination.hasMore` in the response.
3. **Request the next page** While it is `true`, repeat the request with `cursor` set to `pagination.nextCursor` and the same `limit`.

Treat the cursor as opaque. Zapier has no built-in cursor loop, so do the loop in a code step or with its looping tools. Make and n8n have iterators and loops, and n8n's HTTP Request node has a pagination option. Always put a maximum number of pages on the loop. See [Pagination](https://docs.filmo.io/rest-api/guides/pagination) for the details, and [Syncing data](https://docs.filmo.io/rest-api/guides/syncing-data) for how to read only what changed.

## Handle 429 and Retry-After

Each key has 120 requests per minute, and the availability queries have a separate 30 per minute. Every scenario that shares a key shares that quota, and every HTTP step in a loop is a request. When a limit is exceeded the answer is 429 [`rate_limited`](https://docs.filmo.io/rest-api/errors/rate_limited) with a `Retry-After` header in seconds. Wait that long and retry the same request with the same idempotency key. Slow down loops on purpose, and use one key per scenario so one run cannot starve another. See [Rate limits](https://docs.filmo.io/rest-api/guides/rate-limits).

## One Idempotency-Key per record

Platforms retry steps and let you re-run a failed execution. Without a key, each retry can create the record again. Send an `Idempotency-Key` on every write, built from something that stays the same for that record: the id of the record in the source system plus what you do with it (for example `crm-4821-create-contact`). Use a different key for each record, never one for the whole execution. If you re-run an execution after changing the data, the same key with a different body is a 422 [`idempotency_key_reused`](https://docs.filmo.io/rest-api/errors/idempotency_key_reused), which is the signal to use a new key. Keys last 24 hours. See [Idempotency](https://docs.filmo.io/rest-api/guides/idempotency).

Always send your own key to [`POST /api/v1/orders/line-items/returns`](https://docs.filmo.io/rest-api/endpoint-reference/orders/return-order-lines), [`POST /api/v1/purchase-orders/{purchaseOrderId}/receive`](https://docs.filmo.io/rest-api/endpoint-reference/purchase-orders/receive-material-from-a-purchase-order), [`POST /api/v1/treasury/payments`](https://docs.filmo.io/rest-api/endpoint-reference/treasury/record-an-incoming-or-outgoing-payment) and [`POST /api/v1/workflows/{workflowId}/runs`](https://docs.filmo.io/rest-api/endpoint-reference/workflows/run-a-workflow). A retry without it duplicates something that cannot be undone.

## Receive changes from Filmo

Filmo does not send webhooks, but a workflow in Filmo can send an HTTP request to a URL when an event happens, and Zapier, Make and n8n each offer a trigger that receives an incoming HTTP call. Create the trigger on the platform, copy its URL into the HTTP request step of a Filmo workflow, and put a secret in a header of that step. The step has no signature. The step does not retry, but the run is attempted up to three times, so deduplicate on the `Idempotency-Key` header, and keep a scheduled read as the source of truth. The request, its limits and the fields of the event are described in [Syncing data](https://docs.filmo.io/rest-api/guides/syncing-data).

## Avoid loops

> **A scenario can trigger the workflow that called it:** A write from your scenario fires the account's event workflows, and you cannot suppress that per request. If one of those workflows calls your scenario back, the two feed each other without end. Filmo's chain protection does not catch it when the scenario writes with an API key, because that write arrives as a new event of origin `api`. Filter the trigger of each workflow by `origin` to exclude `api`.

- Run the scenario on a schedule and read what changed, as well as or instead of waiting for a call.
- Before writing, compare with the current value and skip the write when nothing changes.
- Mark what the integration wrote, for example with a tag, and make the scenario ignore records carrying that mark.
- Set a ceiling on executions per hour in the platform, so a loop stops by itself.
- Check the account's active workflows before you switch the scenario on (see [Testing](https://docs.filmo.io/rest-api/guides/testing)).

## The first run is the dangerous one

The first execution of a scenario often covers the whole history. Reading thousands of records takes minutes at 120 requests per minute, and each request counts as a task or operation on most platforms, so check your plan. If the first run writes to Filmo, every write can start the account's automations, including ones that email customers. Pause those automations first, run the first load on a small batch, and only then open it up.

## AI agents in Make and n8n

Make and n8n also have nodes that connect to MCP servers, which let an AI step choose Filmo tools by itself. The server is at `https://app.filmo.io/api/v1/mcp`. Start with the [MCP overview](https://docs.filmo.io/mcp/overview), then the steps to connect [Make](https://docs.filmo.io/mcp/connect/make) or [n8n](https://docs.filmo.io/mcp/connect/n8n). For fixed, predictable flows, prefer the HTTP steps described here.

---

Canonical URL: https://docs.filmo.io/rest-api/guides/no-code-platforms  
Last updated: 2026-10-09