When you create a new integration version in Zapier, it goes through different lifecycle states. Understanding these states is crucial for managing your integration effectively. They are as follows:

  • Private
  • Promoted
  • Demoted
  • Legacy
  • Deprecated

​
Private

When you first create a new integration version, it automatically starts in a private state. This is the default state for all new versions.

In the private state:

  • Only you and your team members can access and test the version
  • You can make changes and updates to the integration
  • You can share the version with specific users for testing
  • The version remains private until you take further action

If your integration is public or intended to go public, you can promote a version to make it available to all Zapier users. When a version is promoted:

  • It becomes the default version for all new users
  • It is visible in the Zapier app directory (for public integrations)
  • Existing Zap templates may be automatically updated to use this version
  • You must always have one promoted version for public integrations

Important notes for promotion:

  • Only one version can be promoted at a time
  • When you promote a new version, the previously promoted version will be automatically demoted to private
  • You cannot promote a version that has been demoted, legacy, or deprecated
  • All validation checks must pass before promotion

​
Legacy

A version can be marked as legacy when you no longer recommend it for new users, but it is expected to continue working for any current users. To set a version as legacy:

  • The version must be in a private or demoted state
  • You cannot mark a currently promoted version as legacy
  • Legacy versions can still be used by existing users but are not available for new users

Important considerations for legacy versions:

  • You cannot migrate users to a legacy version

​
Deprecated

Deprecation is the final state in a version’s lifecycle. When you deprecate a version:

  • Users will be notified that they should migrate to a newer version
  • The version will continue to work for a specified time period
  • After the deprecation date, the version will no longer function
  • You must deprecate a private, demoted or legacy version, not a currently promoted version

Important notes about deprecation:

  • Set a future deprecation date to give users time to migrate
  • Ensure you have a newer version available for users to migrate to
  • Consider the impact on existing users before deprecating a version
  • You cannot migrate users to a deprecated version

See Deprecate or delete a version for more information.

​
State Transitions

Here’s how versions typically move through states:

  1. New version starts as private
  2. Version can be promoted (marking previous promoted version demoted)
  3. Version can be marked as legacy (if private/demoted)
  4. Version can be deprecated (if private/demoted/legacy)

Remember that you must always have a promoted version if your integration is public, and you should carefully plan version transitions to minimize disruption to your users.

For more information on managing versions, see:

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

Was this page helpful?