License and 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 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