Zapier, Make and n8n

• Create one key per scenario or Zap, with only the scopes it needs (see 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 to confirm the key works and to see its scopes.

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.

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.

1. 1

   Request the first page

   Send the list request with a limit (the maximum is 500).

2. 2

   Check for more

   Read pagination.hasMore in the response.

3. 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 for the details, and Syncing data for how to read only what changed.

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 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.

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, which is the signal to use a new key. Keys last 24 hours. See Idempotency.

Always send your own key to POST /api/v1/orders/line-items/returns, POST /api/v1/purchase-orders/{purchaseOrderId}/receive, POST /api/v1/treasury/payments and POST /api/v1/workflows/{workflowId}/runs. A retry without it duplicates something that cannot be undone.

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.

• 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).

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.

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, then the steps to connect Make or n8n. For fixed, predictable flows, prefer the HTTP steps described here.