Sample release scenario

Here’s the release procedure for a breaking change explained using a sample scenario.

Assume that we are planning to release a new required field, called bookingDate into the request schema of the /v2/trips/{tripId} endpoint. This is a breaking change since it would require you to adjust your integration code. The following steps will explain how we would release this update.

1. The release timeline will be updated with the initial announcement indicating the upcoming new change. The log will also contain the scheduled date on or after which the release would go live in production.

The above screenshot shows that the initial announcement has been made on March 15th, and the update will be released to production after April 15th, 2025.

2. As mentioned in the backward compatibility policy, we release all new fields in the request as optional parameters. In this scenario the bookingDate will be initially released as an optional field before April 15, 2025. You can use the API changelog to keep track of this release.

3. Once the optional field is released, you should update your code to start sending bookingDetails in the request. You will have until April 15, 2025 to make this code change.

Note: Your existing integration will continue to work until April 15, 2025, since the bookingDetails is an optional parameter at the moment.

4. On or after April 15th, 2025, a final announcement will be made in the release timeline indicating that the bookingDetails has been made as a required field. At this point if your code hasn’t been adjusted to send bookingDetails in the request your API calls will fail.

Here’s an overview of the timeline for this sample release scenario.