# Zapier Release

> Audit a Zapier integration and ship changes without breaking live Zaps. 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.
> Built on the SkillSafe skill @samber/zapier-integration-playbook, from samber/developer-platform-skills (MIT), by
> Samuel Berthe.
> Not affiliated with or endorsed by Zapier.
> Scope: a B2B SaaS vendor's own Zapier integration - building it, publishing it, growing it and changing it without
> breaking live Zaps. Not building Zaps as an end user, not calling existing Zapier apps from code or agents, not choosing
> an embedded iPaaS, not generic marketplace listing work.

https://zapier-release.skillsafe.ai/

## What is free
- Parsing: the definition (the JSON the CLI's build writes, or the Platform UI's export) and the previous version's, each 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 (key, noun, display, operation type, inputFields, outputFields, sample, performSubscribe, performUnsubscribe, performList, canPaginate). Perform code is read as structure only; nothing is ever run.
- The step table: key, label, type (trigger polling, trigger hook, create, search, searchOrCreate), visibility, field counts, sample and the page's class (keep, additive, hide, breaking, rejected).
- The checks, each with an id, the skill's rule and pass, fix, fail, note or n/a; a check that fails on one step carries the step key after a dot: step_names and field_labels (names and copy); id_dropdown and delete_copy (fields); money (never move money); auth_test, auth_label, auth_scheme, auth_refresh, auth_401 and retry_after (authentication); hook_list, hook_subscribe, static_hook, poll_contract and updated_id (triggers); sample_present and sample_shape (samples); step_count, step_order and jobs_cover (steps from customer jobs); breaking_changes; live_zap, live_run and live_users (live runs); elig_launched, elig_ownsapi, elig_https, elig_testacct, elig_admin, elig_another and elig_competitor (eligibility); validation (pasted validation lines); version_rule; deadline_fit.
- The change diff, with the previous version pasted: every change classified as additive (step_added, step_twin, step_shown, input_added_optional, output_added, auth_field_optional_added), hide (step_hidden) or breaking (step_removed, step_renamed, input_removed, input_renamed, input_type_changed, input_required_added, input_made_required, output_removed, output_renamed, output_type_changed, poll_hook_switch, poll_id_changed, auth_type_changed, auth_field_renamed, auth_field_removed, auth_field_required_added), each with its consequence for live Zaps, the additive alternative (a twin under key_v2 with the same name and description, the old step hidden) and how it ships (twin, hide, major or keep). Then what only a hand diff can show - the response structure, changed perform behavior, and the sort order, page contents and id format of each live polling trigger - and the Zap templates to rebuild.
- The version: the next minor of the same major (1.0.3 to 1.1.0), or the next major (2.0.0) when a breaking change ships in place or touches auth; whether the version is still editable (private with fewer than 5 users†).
- The auth ladder (OAuth v2 > a self-serve API key > Session > Basic > Digest), the trigger type per visible trigger (a REST hook only when the API creates and deletes a subscription per Zap and keeps several alive), the grow levers (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 first) and the publish timeline by week from today, each naming the answer that moved it.
- Exports: the step table (.csv), the checks (.csv), the change diff (.csv), everything (.json), the twin-step patch (a JSON patch list, and the merged definition: the old step back from the previous version and hidden, the new one as key_v2 - every value copied from the two definitions, never invented) and a release-notes and help-article skeleton (.md).
- Saved integrations keep a compact snapshot of the checks: reopening one, or pasting an integration of the same name, shows what changed since it was saved.
- 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, 95%† of more than 20 runs† over 7 days†, 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; the app never promises one.
- † verify against Zapier's live docs before quoting it.

## The metered lanes
Two tasks on gpt-terra, metered per run, routed by `task`. Input string fields: `task` (plan or release), `integration` (the interview answers), `definition` (the definition as read, one line per step), `previous` (the previous version as read, or empty), `diff` (the page's change rows, the hand-diff list, the templates to rebuild and the target version, or empty), `jobs`, `evidence` (live-run lines and validation lines), `carry` (release only: the plan's step classes and fixes), `facts` and an optional `retry_note`.
- `plan` replies with `summary`, `route`, `steps` (`key`, `label`, `type`, `class` keep, additive, hide, breaking or rejected, `reason`), `auth` (`decision`, `rests_on`), `trigger_types` (`key`, `decision` polling or hook, `rests_on`), `fixes` (`check`, `change`), `publish` (`item`, `owner` a role, `week`), `grow` (`lever`, `why`), `footnote` and `caveats`.
- `release` replies with `summary`, `target` (`version`, `why`), `changes` (`step`, `change`, `class`, `ship` twin, hide, major or keep, `note`), `by_hand` (`what`, `how`), `canary` (`how`, `watch`), `migrate` (`when`, `deprecate`), `templates`, `notice` (each item on its own line), `footnote` and `caveats`. It needs the previous version.
A reply stays on the page when the form changes after it ran, under an out-of-date banner, and its downloads and copies keep working; each plan fix and each release change copies on its own, and the plan's handoff carries its step classes into the release lane.
The page holds every reply to its own facts: the plan keeps the page's route, every definition step exactly once with the page's type and class, the auth pick and every trigger decision with the capability behind it, a fix for every fail check, publish owners by role in the page's weeks and the grow levers in the page's order; the release keeps the page's target version, one change per diff row with the page's class and ship (never a breaking change shipped as keep), every hand-diff item, the canary for the tooling, Monitoring, legacy or a dated deprecation as answered, exactly the page's templates, and a notice one item per line that never promises Zapier will email everyone; both carry the dagger on every Zapier platform number, the footnote, no URL, no backticks, no implied Zapier endorsement and no delisting threshold.

## Links
- API tutorial: https://zapier-release.skillsafe.ai/api.html
- Source skill: https://skillsafe.ai/skill/@samber/zapier-integration-playbook
- Source repository: https://github.com/samber/developer-platform-skills