Backward Compatibility

Spotnana APIs support backward compatibility, ensuring your integrations continue to function smoothly as our APIs evolve.

What is Backward Compatibility?

An API is considered to be backward compatible if it can handle requests from a client using an older version of the API without breaking or returning errors.

Spotnana’s Backward Compatibility Policy

While we are frequently adding features to our platform and APIs, we ensure that we are following a backward-compatible approach during our development process. What this means is that:

Expect new or unknown fields to be added to the APIs: We frequently release new fields to our existing APIs to provide additional platform features. While the new fields we release are always non-breaking changes, your parsing code must be flexible enough to accept these changes gracefully (i.e., not fail or generate an error).

Note: Your codebase should be designed to allow new or unknown fields and enums in the API response.

New response fields are non-breaking: Our releases, which often involve adding new fields to an API response, are always non-breaking changes. You can treat the new or unknown fields in an API response structure as optional parameters. However, it’s crucial that your application is designed to gracefully allow these new changes.
No breaking changes: We avoid introducing changes that would disrupt existing integrations within the same API version.
Deprecated fields are highlighted: Our upgrades may sometimes deprecate selected fields within an API endpoint. These fields will be labeled as Deprecated in our developer portal documentation and would appear as shown in the following screenshot.

Fig: A deprecated field labeled in an API.

Best Practices

Spotnana's platform and APIs are constantly evolving and adding features to provide a great travel booking experience for our partners. Keeping that in mind, here are some best practices we recommend when you are integrating with our APIs:

Review our API Documentation: Our developer portal documentation will be updated to reflect any new fields, enum or deprecated fields. Regularly review our documentation to keep track of our latest developments to APIs.
Expect new or unknown fields: While the new fields we release to APIs are always non-breaking changes, your parsing code should be designed to handle any new or unknown fields on our API response.
Include our API changes in your development lifecycle: We recommend that you regularly review and accommodate any changes to our APIs as part of your normal development lifecycle. This will ensure that you get the maximum functionality from of our APIs.