TSI APIs

TSI APIs are organized around the principles of REST (Representational State Transfer). TSI APIs accept:

1. JSON-encoded request body
2. standard HTTP verbs - HEAD, PUT, POST, DELETE, and GET
3. Bearer Authentication

APIs consistently produce:

1. JSON-encoded responses
2. standard HTTP response codes.

View the Swagger-styled API documentation.

Authentication

The API requests require authentication and are secured by token based authentication. The Authorization HTTP header can be specified with Bearer <your-access-token> to authenticate as a user and have the same permissions as the user itself.

You can find your access token under API Tokens.

HTTP Codes

TSI APIs use conventional HTTP response codes to indicate the success or failure of an API request. In general codes in the 2xx range indicate success. Codes in the 4xx range indicate an error that failed given the information provided. Codes in the 5xx range indicate a TSI processing error.

Some 4xx errors that could be handled programmatically include an error message in the response.

HTTP Responses

TSI APIs return JSON-encoded response. Following are the system managed properties that are also returned along with the requested object.

Property	Use
tenant	This is an account ID to which the returned object belongs to.
type	This is the type of the returned object. This is in format entities.<object_name>. For example: an Episode API response has type set as entities.Episode.
createTime	This is the time when the returned object was created. This time is in milliseconds format.
updateTime	This is the time when the returned object was updated. This time is in milliseconds format.
createdBy	This is the user ID who created the returned object. For system-created objects, this is set as pod.
updatedBy	This is the user ID who updated the returned object. For system-updated objects, this is set as pod.

API Deprecation & End-of-Life Policy

APIs are deprecated when they are no longer actively supported or maintained. There are variety of reasons, including:

1. Security vulnerabilities: If an API is discovered to have a security vulnerability, it may be deprecated to protect you from potential attacks.
2. Changes in technology: As technology evolves, APIs may need to be updated to keep up. If an API is not updated, it may become outdated and deprecated.
3. Release of a new API with improved functionality: When a new API is released with improved functionality, the old API may be deprecated. This allows Falkonry to focus on supporting and maintaining the new API.

Falkonry follows a 6-month deprecation process for all APIs. The process begins when a new API is released that replaces the deprecated API or offers net new functionality.

Note

During the deprecation period, Falkonry will communicate the deprecation to you through the product update emails and update the API documentation to notify you that the API is deprecated.

API Deprecation Process:

1. Release of a new API: A new API is released that replaces the deprecated API or offers net new functionality.
2. Communication of deprecation: Falkonry communicates the API deprecation to you through the product update emails and updates the API documentation to notify you that the API is deprecated.
3. 6-month deprecation period: You have 6 months to update the API usage and integrations.
4. Retirement of the API: The deprecated API is retired and is no longer available. Attempting to call a retired API will result in a 404 HTTP response code.
5. Removal of documentation: All documentation about the retired API and its versions is removed, and you are redirected to the new API documentation.

After 6 months, the deprecated API will be retired and will no longer be available. Attempting to call a retired API will result in a 404 HTTP response code. All documentation about the retired API and its versions will be removed, and you will be redirected to the new API documentation.