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 ypur 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
- 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 - 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||-||✓||✓||-||-|
|Partner’s API (overall)||-||Depends||Depends||Depends||-|
|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.