Versioning

Backwards-compatible changes

YCloud API considers the following changes to be backwards-compatible (non-breaking):

• Adding new API resources.
• Adding new optional request parameters to existing API methods.
• Adding new properties to existing API responses.
• Changing the order of properties in existing API responses.
• Changing the length or format of opaque strings, such as object IDs, error messages, and other human-readable strings.
  This includes adding or removing fixed prefixes (such as evt_ on Webhook Event IDs).
  You can safely assume object IDs we generate will never exceed 255 characters, but you should be able to handle IDs of up to that length. If for example, you’re using MySQL, you should store IDs in a VARCHAR(255) COLLATE utf8_bin column (the COLLATE configuration ensures case-sensitivity in lookups).
• Adding a new value to an enum.
  For example, adding new event types. Your webhook listener should gracefully handle unfamiliar event types.

Versioning

Sometimes it is necessary to make backwards-incompatible (or "breaking") changes to an API. These kinds of changes can cause issues or breakage for code that has dependencies on the original functionality.

YCloud API uses URI versioning to prevent breaking changes:

https://api.ycloud.com/v1/balance
https://api.ycloud.com/v2/balance

The latest version is v2.