Skip to main content

REST APIs

Atoti & Database​

Atoti REST API allows one to queries against the cube. To prepare these queries and understand the structure of the cube, endpoints provide descriptions of the Cube hierarchies and measures. You can also add new MDX members and measures.

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​

DataExport 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 service provides you with a way to investigate measure lineage (various measures implemented, and dependencies between them) for the cubes available within your project.

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 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.