Versioning Schedule
Find out more about our versioning strategy and evolving schema
Evolving Schema
Innovation is all about increasing momentum and staying ahead of the curve. Which is why we've designed Rapid 3 so you'll never need to break your stride.
With Rapid 3 and our evolving schema, you get features as soon as they're ready. No more waiting six months for new releases. No more taking hours to upgrade with each new release.
Our latest feature releases won't break your integration, so you can stay on Rapid 3 for longer, saving you time and money. We'll also let you know what features are coming, so you can plan ahead.
Versioning strategy
When we release larger features, or breaking changes, we'll launch them onto a new version, e.g. Rapid 4.
Our Rapid Technology teams maintain one active version of the API, with another in development. When we launch the latest version that's been in development, it will become active, and the previous version will be marked as deprecated. A deprecated version will be available for one year before we retire it, to give you enough time to move to the latest and greatest. During that time, only major security fixes will be rolled out to the deprecated version.
Terminology
Here are a few definitions to help you understand our versioning schedule:
Active: The current, active version of Rapid. Non-breaking change features can be added to an active version at any time, and you decide whether to integrate these features or not.
Development: The upcoming version of Rapid that we are working on.
Deprecation: When a version is marked for deprecation, it is an indication that the version will no longer be available after one year. This is a good time to upgrade to the latest active version.
Retired: Once a version is retired, that version will no longer be accessible via the API.
Non-breaking changes: Non-breaking changes are features which can be added to an active version at any time and will not break your integration.
Non-breaking changes include:
- New endpoints added
- New optional query parameters added
- New optional request fields added to request bodies
- New optional headers added to the request
- Mandatory request parameters become optional
- New fields added to a response
- New headers added to the response
- New values added to a request enum
- New values added to a response enum with a default
Breaking changes: Breaking changes are larger feature updates that can break your existing integration. We will only release breaking changes to a new active version of Rapid, so you don't have to worry about your existing integration.
Breaking changes include:
- Existing endpoints removed
- New required query parameters added
- New required request fields added to request bodies
- New required headers added to the request
- Optional request parameters becoming required
- Removing or renaming query parameters
- Removing or renaming response fields
- Changing the type of query parameters
- Changing the type of request fields in a request body
- Adding new validation requirements to existing parameters
- Removing or eliminating Authentication or Authorization configurations
- Removing or renaming enum values
- New values added to a response enum with no default