Zapier automation and Zapier integrations

Zapier suits event-by-event workflows between apps:

• The apps you use, such as your CRM, accounting and messaging tools, already have Zapier triggers and actions.
• Each run handles one event: a new contact, an order, a status change, a paid invoice.
• People on your team should be able to see and change the steps without a code deploy.
• Your product should be available to Zapier users. A Zapier integration defines its authentication, triggers and actions on the Zapier Platform.

Plan around these before you commit:

• You need to move data that already exists. Triggers do not fire for data created before the Zap was turned on. Zapier points to its Transfer feature for that.
• A step calls a slow API. Zapier actions time out after 30 seconds, so long jobs need a callback or your own service.
• You run high volumes. Every successful action is a task. On a plan without pay-per-task billing, Zapier holds new runs once the task limit is reached, until the billing cycle resets.
• The logic is long and branchy. A Zap has a step limit, paths nest only three deep, and a Paths step must be the last step. At that point code is easier to test and change.

A Zap starts from a trigger. Most triggers poll: Zapier checks the app for new items and runs the Zap for each ID it has not seen. Instant triggers receive data by webhook as soon as the event happens. A Zap with more than one action, or with filters or searches, is a multi-step Zap. Filters stop the run when data does not meet a condition. Paths send data down different branches, run left to right, and can end in a fallback branch. Formatter changes text, numbers and dates, and maps values with lookup tables. Delay holds a run for a set time or until a date, or queues runs one at a time for apps that accept data slowly. Webhooks by Zapier gives your own system a unique URL: Catch Hook parses the body, and Catch Raw Hook passes the raw body and headers. A request carrying an array of objects can run the Zap once per object.

• Task usage: each successful action is a task. Triggers, filters, paths, Formatter and Delay steps do not count, and neither do actions that error.
• Error handlers: a step can have its own error path that runs only when it fails, with the error message available to later steps. Zapier sends no error email when a handler runs, and autoreplay is turned off for that Zap, so the handler must alert someone.
• Replay: errored runs can be replayed by hand, or automatically with autoreplay. Replaying a whole run reruns every step, including the trigger, and its successful steps count as tasks again.
• Held runs: when the task limit is reached, new runs are held and can be replayed later. We check usage before a busy period, not after.
• Splitting work: when one run would fetch many records, we split it across several Zaps or move the fetch into your own service.

Not sure which tool fits? See how we choose between Zapier, Make, n8n and custom code.

• Platform UI or CLI: the Platform UI is a browser-based editor, and the Platform CLI builds the integration locally in JavaScript, with Git and automated tests. A UI integration can be exported to the CLI. Going back is not direct.
• Authentication: the Platform UI supports API key, OAuth v2, session, basic and digest authentication. Zapier prefers OAuth v2 where possible. Custom schemes need the CLI.
• Polling triggers: your endpoint returns items newest first, and Zapier deduplicates them on their ID. Changing the ID format makes old records fire again.
• REST hook triggers: Zapier calls your subscribe endpoint when a Zap is turned on and your unsubscribe endpoint when it is turned off. Your app posts each event to the URL stored for that Zap, and stops when Zapier answers 410. A sample-data endpoint lets users map fields in the editor, and public integrations must have one.
• Actions and searches: each must answer within 30 seconds. Longer work uses Zapier's callback service, and the step waits until your app posts the result.
• Publishing: a public listing is for the company that owns the API or developers it contracts. The app must be fully launched, Zapier needs a test account, and every trigger, action and search must have a live test Zap with a successful run. Otherwise the integration stays private.

1. Map the flow and the volume: which events, which apps and roughly how many runs a month, because every successful action is a task
2. Build with failure in mind: error handlers on steps that call other systems, an alert when one runs, and a replay plan
3. Test with real records: including duplicates, empty fields and the old data a trigger will not pick up
4. Hand over properly: each Zap named and documented, with notes on reading Zap history and replaying a failed run