Planning and implementing integration changes

Before making updates to your integration, it’s important to consider the potential impact on user migration and existing Zaps. Ensuring your API and Zapier integration remains backwards compatible is crucial to avoid disruption to users. However, we acknowledge certain changes are sometimes necessary and unavoidable. In such cases, consider the best practice for implementation.

Effects of Different Changes (Versioning Matrix)

The matrix below illustrates the impact of different changes on your users. For public integrations, this will affect promotion and whether migration is possible. Refer to our best practices to facilitate the upgrade process for yourself and your users.


  • Add: Adding a net new component
  • Update: Making a change to an existing component
  • Replace: Deleting/deprecating an existing component and adding a new one in its place
  • Delete/Deprecate: Removing an existing component completely

Matrix Key:

  • Breaking Change: A modification to the integration which renders existing Zaps incompatible with the new version
  • Depends: A modification which may render existing Zaps incompatible with the new version, depending on the implementation
  • ✓: A modification to the integration which renders existing Zaps compatible with the new version
  • -: Not applicable

Common changes that can affect the ability to migrate users are detailed in the documentation linked in the matrix. Look for your change and pay attention to the recommended best practices.

Several change scenarios are validated by the platform when you try to Migrate after a version promotion, but always be aware of the effects of any changes you make before you even begin implementing those changes.

Change scenarios marked as Depends with no linked best practice can vary widely across integrations, so a generalized best practice is not provided; reach out to support if you need help with your specific change scenario.

Integration Change Add Update Replace Delete/Deprecate Validated by platform?
Authentication schemes BREAKING CHANGE - BREAKING CHANGE -
Authentication fields - required BREAKING CHANGE Depends - -
Authentication fields - optional - -
Authentication field key(s) - BREAKING CHANGE - - -
Authentication - token request - - - -
Authentication - test function - - -
Trigger/Action - meta info (e.g.: label, description) - - -
Trigger/Action - input field(s) - required Depends Depends Depends -
Trigger/Action - input field(s) - optional -
Trigger/Action - input field(s) - key - BREAKING CHANGE BREAKING CHANGE - -
Trigger/Action - input field(s) - field type - Depends Depends - -
Trigger/Action - output data - response structure - BREAKING CHANGE BREAKING CHANGE - -
Trigger/Action - perform function - Depends Depends - -
Trigger type - polling to hook type - BREAKING CHANGE - -
Trigger (polling) - perform function - Depends Depends - -
Trigger (hook) - perform list - Depends Depends - -
Trigger (hook) - performSubscribe - - -
Trigger (hook) - performUnsubscribe - - -
Middleware Depends Depends Depends Depends -
Partner’s API (overall) - Depends Depends Depends -
Product feature - - - -
Rebrand - (e.g. logo, app name) - - - -
Export UI to CLI - Depends - -
Export CLI to UI - Depends - - -
Edit Legacy Web Builder integration - Depends Depends - -

If your change is not listed, make sure to still consider whether it changes keys, requires users to provide new info, or revokes functionality.

Need help? Tell us about your problem and we’ll connect you with the right resource or contact support.