For SaaS vendors who own a Zapier integration
Zapier ReleaseWill this version publish - and which change breaks a live Zap?
Paste your Zapier integration's definition, and the previous version's, and get every step audited against Zapier's design and publishing rules and every change classified as additive or breaking for live Zaps, then the publish plan or the versioning plan for the change. Your browser reads both definitions and flags a renamed or removed key, a trigger switched between polling and REST hook, a required input with no default, an auth change, a visible static webhook, a step that moves money, a missing sample and fewer than 3 users† with a live Zap, computes the next version, writes a twin-step patch and lays out the publish timeline by week.
The integration and the previous version free
Read with JSON.parse; a paste that does not parse is named by its line and column. Read: version, platformVersion, authentication (type, fields, test, connectionLabel, oauth2Config.autoRefresh) and every step under triggers, creates, searches and searchOrCreates (display, operation type, inputFields, outputFields, sample, performSubscribe, performList). Perform code is read as structure only - nothing is ever run.
The interview - each answer moves a check, a ladder or the timeline free
Publishing needs one live Zap and one successful run per visible step, in the admins' Zap history; hide steps nobody can exercise.
A template on a step the release hides must be rebuilt and resubmitted on its replacement.
The checks free
What the page flags
The definition as read
The step table
Every check, rule by rule
The change diff - what it does to live Zaps
The version
Auth and trigger types
The grow levers, re-ranked
The publish timeline, by week
Your stage and the route
The twin-step patch, the release notes and the exports free
The twin-step patch
For each step a breaking change touches, the old step comes back from the previous version with display.hidden true and the new one goes in as <key>_v2, same name and description - a JSON patch list, or the merged definition. Every value is copied from the two definitions you pasted; nothing is invented, and an auth change, which no twin carries, is named instead.
The release notes and help-article draft
Hidden steps and their replacements, what users do, and the help-article outline per job.
The audit and publish plan metered
Pricing as soon as the session is ready...
Sign inThe reply could not be read. Here it is as it came back:
Caveats
Caveats
The page's check of this reply
Saved integrations
How it works - and what is sourced
The checks follow the skill's Design list, its Publish steps, its Grow order and its Maintain rules, plus its references on the platform rules, the CLI build and versioning. Both definitions are read with JSON.parse; a paste that does not parse is named by its line and column. Perform, subscribe and list functions are read only as structure - present or not, and a signature to compare versions with; no source is ever run. A step's class comes from the change diff: a new step, a new optional input or output, or a twin under a new key is additive; a newly hidden step is hide; a renamed or removed key, a changed input type, a required input with no default, a polling-to-hook switch, a changed id on a live polling trigger and any auth change are breaking. Promotion does not catch renamed output keys, a changed response structure or changed perform behavior, so the page lists what to diff by hand.
The release target is the next minor of the same major when nothing breaking ships in place, else the next major - and an auth change always needs a new major. The auth ladder runs OAuth v2 > a self-serve API key > Session > Basic > Digest; a trigger is a REST hook only when the API creates and deletes a subscription per Zap and keeps several alive. The grow levers run templates > a template in the launch post > the Workflow Element > onboarding and support > spotlight > a Workflow API marketplace; a date moves the launch-post template to the top. The timeline counts weeks from today; the week to clear fails and recruit before submitting is the page's own assumption, named where it is used. A saved integration keeps a snapshot of its checks, so reopening it shows what changed since you saved it.
Every Zapier platform number carries a dagger: 3 users† with a live Zap; fewer than 5 users† for an editable version; 100 items† per poll; 250 characters† per error; a Zap erroring on 95%† of more than 20 runs† over 7 days† turns off; 90 days† of Beta; about a week† for the reviewer and about another week† per fix round; about 2 weeks† of template review; four weeks† between submission and the date; 5-10 Zap templates†; a canary of 5-10%† for 30-60 minutes†; a deprecation date 3 weeks† to 1 year† ahead, Zapier's email 14 days† before; Silver at 50 active users†. Zapier documents no integration-level error threshold for delisting, and the page never promises one.
† verify against Zapier's live docs before quoting it.