Sisense REST API

What is the Sisense REST API?

Sisense provides advanced users and developers a RESTful web API to most of its server functionalities, from user management to manipulating datamodels, dashboards & widgets.

To get started with the Sisense REST API, refer to Using the Sisense REST API

What can I use the Sisense API for?

These are a few examples of common use-cases for the REST API:

• Use Sisense data in your application or website
  For example: you could implement a widget in your own corporate website that takes data from Sisense using the JSON Analytical Query Language (JAQL) or standard SQL and the query API.
• Automate a process
  For example: you could write a script that adds multiple users from a CSV file, using the users API.
• Implement your own UI on top of Sisense
  For example: you could develop an elaborate dashboard navigation page to function as a "home page" for your organization, using the dashboards API.

Quickstart Guide

Learn to use the Sisense REST API

Data Models Tutorial

Create and modify Sisense Data Models using the REST API

Data Security Tutorial

Configure row-level security tules using the REST API

API Versions

The Sisense REST API currently supports 3 API Versions, represented as part of the API endpoint path:

REST API v0.9

Legacy APIs, available via the `/api/` path.

REST API v1.0

Most application APIs, available via the `/api/v1/` path.

REST API v2.0

Sisense's latest APIs, only available on Linux versions, via the `/api/v2/` path.

These versions were created as a result of changes in the product features & API standards over time, and therefore do not contain the same set of endpoints and capabilities - for instance, a feature added recently will be represented in API v2, but will not have corresponding endpoints in the two older API versions.

Which API version to use

In most cases, the endpoint you need will only exist in one of the API versions. For example, Datamodel schema manipulation is only available via the v2 API.

In case the capability exists in two (or more) API versions, it is recommended to use the newest one (highest version number).

How APIs change over time

• Incremental changes to APIs that are non-breaking, such as adding new optional parameters or supported parameter values, are usually done on the existing API version.
• Significant reworks of an API usually result in a new API version, or the migration of an existing older API to a new version while keeping the original APIs intact to avoid breaking changes.
• APIs that have been upgraded/migrated to a newer API version will remain supported as long as they are in wide use.
• Once most use cases have been refactored to use the new APIs, the older endpoints will be marked as deprecated.
• Deprecated APIs will remain active for several major versions to ensure all users have the opportunity to update their code.