When you save files in the editor, your changes are moved into the latest draft. The latest draft represents the
current working state of your integration. When you deploy, unless deploying froma version, it is the latest draft
that gets deployed — so always ensure your latest draft reflects the state you intend to release.
Why use versions
As your integration evolves — new workflows, updated mappings, revised error handling — you need a way to track what changed and when. Without versions, every edit overwrites the previous state with no way to recover it. Versions solve this by giving you:- Change history: See exactly what your integration looked like at any point in its development.
- Safe rollbacks: Revert to a known working state instantly if a change introduces issues.
- Deployment control: Choose precisely which version of your integration runs in each environment.
- Team coordination: Give collaborators a clear record of what changed and why through version names and descriptions.
- Audit trail: Maintain a log of how your integration has evolved over time for compliance and troubleshooting.
Creating versions
A version requires a name and accepts an optional description. The name identifies the version at a glance, while the description provides a summary of what changed — making it easier to understand the purpose of each version when reviewing history.Versions are shared across all available environments and can be deployed to any environment.
Manual version creation
You can create a version at any point during the development of your integration. This is useful when you want to checkpoint your work before making a large change, or when you reach a stable milestone worth preserving.Open the Version History popover
Navigate to your project and select the Version History popover in the header.
Create a new version
Click +, enter a name for the version, and optionally provide a description summarising the changes included.
Automatic version creation on deployment
When you deploy an integration, a new version is automatically created. This ensures every deployment is tied to a specific, immutable snapshot of your integration code and configuration. You do not need to create a version manually before deploying — the platform handles it for you. However, you are still prompted to provide a name and optional description so the deployment version is clearly identifiable.
Even though versions are created automatically on deployment, you can still create manual versions at any time.
Manual versions are useful for checkpointing work-in-progress that you are not yet ready to deploy.
Switching between versions
You can switch between any previously created version to review its state or restore it as the active working version. This is particularly useful when comparing changes across versions or when you need to return to an earlier implementation.Select a version
Choose the version you want to switch to. You can use the name and description to identify the correct version.
Rolling back to a previous version
If a recent change causes issues — failed executions, incorrect data mappings, or unexpected behaviour — you can roll back to a previous version to restore a known working state. Rolling back replaces the current integration state with the selected version. This is the fastest way to recover from a problematic change without manually undoing edits.Deploying a version
When you deploy an integration, the platform creates a new version. This means every deployment is traceable back to a specific version. You can also deploy a previously created version to an environment without making further changes — useful when promoting a tested version from development to production.Choose the version to deploy
From the Version History popover, select the version you want to deploy. If you are deploying your current work, the
platform creates a new version automatically.
Select the target environment
Choose which environment to deploy to (e.g. development, staging, production). Each environment runs independently
with its own connections and credentials.
Version naming strategies
A consistent naming convention makes it easier to identify versions at a glance, communicate changes across teams, and maintain an organised version history. Below are some common strategies.Semantic versioning
Use a structuredmajor.minor.patch format to communicate the scope of changes.
| Version | When to use |
|---|---|
1.0.0 | Initial stable release |
1.1.0 | New feature added (e.g. added product sync workflow) |
1.1.1 | Bug fix or minor correction (e.g. fixed date format mapping) |
2.0.0 | Breaking change or major rework (e.g. migrated to v2 API) |
Semantic versioning works well when your integration has external consumers or when you need to clearly signal the
impact of each change.
Date-based versioning
Use the release date as the version name for a chronological record.| Version | Description |
|---|---|
2026-03-09 | Daily release snapshot |
2026-03-09.1 | Second release on the same day |
2026-Q1 | Quarterly milestone release |
Feature or milestone naming
Name versions after the feature or milestone they represent for a human-readable history.| Version | Description |
|---|---|
order-sync-v1 | First version of order synchronisation |
multi-tenant-support | Added multi-tenant capabilities |
api-v2-migration | Migrated all endpoints to API v2 |
pre-launch-final | Final version before go-live |
Combining strategies
You can combine approaches to get the best of both worlds.| Version | Description |
|---|---|
1.2.0-order-retry-logic | Semantic version with feature context |
2026-03-09-hotfix-auth | Date-based with change summary |
2.0.0-rc1 | Release candidate before a major version |