License & Disclaimer

Nobody likes breaking changes when using third-party resources. So we want to be clear about the limitations, constraints, and support we provide for our APIs. This text is aimed both at you as a company, but also the developers within that company who plan to use our public API’s.

License and Disclaimers

Users are permitted to use our public REST APIs to facilitate their use of the Kindly platform in a manner consistent with the rights they’ve separately purchased from Kindly, during the term of their license or subscription.

Other terms and conditions can be found at https://www.kindly.ai/legal/terms-of-service.

Backward Compatibility and Limitations

The last thing developers and businesses need is to be surprised that a crucial endpoint is no longer reachable, behaving unexpectedly, or has changed in any way that disrupts or breaks an established workflow. We take steps designed to ensure backwards compatibility of our APIs.

We consider the following changes to be backwards-compatible:

Additive changes:

• Adding a new resource (i.e. adding a new URL or path to the APIs).

• Adding new optional request parameters.

• Adding new JSON fields in API responses.

• Changing the order of properties in API response.

• Changing the length or format of strings in error messages.

Limits and Constraints:

• Your API client consumer should gracefully handle any of the additive changes above.

• If a resource is being consumed at a rate which puts the integrity of the Kindly platform and/or service degradation is at risk, Kindly may choose to apply sensible concurrency and rate limits, even if an individual resource has no rate limits currently.

Upgrades and versioning

Kindly release changes to its products continuously, and non-breaking changes are introduced with no prior announcement.

Deprecations, and Sunsetting:

• When breaking changes are required to innovate and evolve the Kindly platform, we will provide version updates for individual APIs as designated by changes to the next whole number -- for example, /v1/metrics, /v2/metrics, etc. This way our users can still continue using their API version until they are ready to upgrade.

• Each individual API is versioned separately. For example, we might publish a v2 of the Statistics API without upgrading the others.

• Once a new version is released, the old version may be deprecated as legacy. Depreciation shall be announced at least three months ahead of time. Sunsetting of deprecated API shall be announced at least six months ahead of time. Only exceptions to these are if we measure no usage of an API within the last three months.