Skip to main content

REST APIs

Atoti & Database​

The Atoti REST API allows you to run queries against the cube. To prepare these queries and understand the structure of the cube, the Discovery REST API provides descriptions of the cube hierarchies and measures. You can also add new MDX members and measures using the Configuration REST API.

When exposed, the Database REST API is accessible for querying and even editing, using Mongo-like requests. Branches are supported and can be manipulated from the API.

Content Service​

The Content Service offers a REST API that allows you to manipulate the folders and files stored in it. Additionally, you can import and export a given folder of documents.

DataExport​

The Data Export service allows you to download the result of MDX queries to a stream or directly export them to files in the server or in the cloud. The exports can be customized.

Diagnostics​

The Diagnostics REST API provides a way to investigate measure lineage (various measures implemented, and dependencies between them) for the cubes available within your project.

XMLA Endpoint​

The XMLA Endpoint provides an XML for Analysis (XMLA) interface for executing MDX queries and performing OLAP discovery operations. This endpoint enables connectivity from OLAP clients like Microsoft Excel.

The XMLA endpoint supports:

  • MDX query execution: Submit MDX queries and retrieve results
  • OLAP discovery: Discover cube metadata, dimensions, hierarchies, and measures
  • Session management: Create and manage XMLA sessions for stateful operations

For more details, see the XMLA endpoint documentation.

JWT Endpoint​

The JWT Endpoint provides an endpoint for retrieving JSON Web Tokens (JWT) for authenticated users.

For more details, see the JWT endpoint documentation.

API versioning and discovery​

What are API versions and revisions​

Atoti REST APIs use a two-level versioning system:

  • Versions (for example, v10, v9): Major API versions that may introduce breaking changes. Different versions can coexist in the same deployment.
  • Revisions: Fine-grained tracking within a version. Revisions track non-breaking changes such as new endpoints, optional parameters, or additional response fields.

The version API endpoint allows clients to discover which API versions and revisions are available in a deployment, enabling feature detection and graceful degradation.

How to query API versions​

The version API is available at /versions/rest and accepts an optional includeRevision query parameter:

GET /versions/rest

This returns basic version information without revision numbers:

{
  "version": 1,
  "serverVersion": "6.1.13",
  "apis": {
    "pivot": {
      "versions": [
        {"id": "v10", "restPath": "/activeviam/pivot/rest/v10"},
        {"id": "v9", "restPath": "/activeviam/pivot/rest/v9"}
      ]
    }
  }
}

To include revision information, add the includeRevision=true parameter:

GET /versions/rest?includeRevision=true

This returns extended version information with revision numbers:

{
  "version": 2,
  "serverVersion": "6.1.13",
  "apis": {
    "pivot": {
      "versions": [
        {"id": "v10", "restPath": "/activeviam/pivot/rest/v10", "revision": 2}
      ]
    }
  }
}
note

The response DTO version changes from 1 to 2 when revision information is included.

When revisions are incremented​

Revisions are incremented when non-breaking changes are added to an API version:

  • New endpoints: Adding a new REST endpoint to an existing version
  • Optional parameters: Adding optional query parameters or request body fields
  • Response extensions: Adding new optional fields to response objects

Revisions are not incremented for:

  • Breaking changes: These require a new major version
  • Bug fixes: Internal fixes that do not change the API contract
  • Documentation updates: Changes to documentation without API changes

Backward compatibility guarantee​

The revision system maintains strict backward compatibility:

  • Lower revisions: All features from lower revisions remain available in higher revisions
  • Optional inclusion: The revision field only appears when explicitly requested with includeRevision=true
  • No breaking changes: Incrementing a revision never breaks existing clients
  • Version independence: Different versions maintain separate revision counters

Clients can safely ignore revision information if they do not need feature detection. The API continues to work without checking revisions.

Miscellaneous​

The Version REST API offers details about the exposed services, their versions and the URLs of these services. For information about API versioning and revisions, see API versioning and discovery.