Planning and implementing integration changes

Before making updates to your integration, it’s important to consider the potential impact on user migration and existing Zap workflows. 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.

Changes marked as “Breaking Change” require a major version bump (e.g., 1.x.x → 2.0.0). Non-breaking changes can use a minor or patch version. See Version numbering for detailed guidance and examples.

Columns:

• 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 Zap workflows incompatible with the new version

• Depends: A modification which may render existing Zap workflows incompatible with the new version, depending on the implementation

• : A modification to the integration which renders existing Zap workflows 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 CHANGES
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 CHANGES
Trigger/Action - meta info (e.g.: label, description)	-			-	-
Trigger/Action - key	-	BREAKING CHANGE	BREAKING CHANGE	-
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 - key(s)		BREAKING CHANGE	BREAKING CHANGE	BREAKING CHANGE	-
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	-			-	-
OTHER CHANGES
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.