Zapier integration playbook

You own a SaaS product's integration on Zapier: a set of triggers, actions and searches that thousands of users wire into Zaps you never see. Every live Zap depends on today's keys and field shapes.

Changes that break live Zaps

Zapier's change matrix and deduplication docs make each of these breaking in effect. Each stops existing Zaps, floods them, or forces users to rebuild them by hand:

• Renaming or removing a trigger, action, input-field or output-field key.
• Changing an output's response structure, or an input field's type.
• Switching a trigger between polling and REST hook.
• Changing the auth scheme, renaming an auth field, or adding a required auth field.
• Adding a required input field, unless it defaults.
• Changing what counts as "new" on a live polling trigger: sort order, page contents or id format. Each live Zap's dedupe memory holds the old ids, so the first poll after the change fires every unseen item as new.

Ship the replacement beside the original instead: copy the step under a new key (new_invoice_v2) with the same name and description, make the change there, hide the old step. Old Zaps keep running; new Zaps get the new step. Hiding a step invalidates every Zap template built on it: rebuild and resubmit those templates on the new key. Breaking changes that cannot ship this way need a new major version, and Zapier blocks user migration across majors: every user updates their Zaps manually.

Promotion blocks most schema-level breaking changes inside a major, but not renamed or removed output keys, changed response structure, or changed perform behavior. Diff those yourself before every promotion.