​
Overview

When backwards-incompatible updates to non-beta products are made, a new API version is released to avoid breaking changes for developers. When a new version is released, you can choose whether to continue using an existing API version or update your application to the newer version to take advantage of new features, improvements, and fixes. To specify the API version of a request, use the Knot-Version header. If the Knot-Version header is not provided in a request, it will default to major version 2.0 of the API. It is recommended to include the Knot-Version header, like below. 
curl -X POST 'https://development.knotapi.com/session/create' \
  -u 'bd271e95-14e6-47ab-9f4f-225898f69183:cf819749c0574616ba93b5935b8cf108' \
  -H 'Content-Type: application/json' \
  -H 'Knot-Version: 2.0'

​
Backwards Compatible Changes

Knot considers the following changes to be backwards compatible (i.e. non-breaking):
  • Adding new API endpoints
  • Adding new optional parameters to existing API endpoints
  • Adding new properties to existing API response schemas
  • Adding new values to enum fields in API responses
  • Adding new webhook events
  • Adding new properties to webhook event payloads. Ensure your webhook logic can gracefully handle unfamiliar event types.
  • Changing the length, format, or content of human-readable strings (error messages, etc.)