Ellipse Gradient for Header

Sisense Integration Guide

Integrate Sisense analytics, dashboards, data models, users, and groups with enterprise systems through REST APIs, scheduled workflows, and selected notification mechanisms.

Sisense integration options at a glance

Sisense primarily integrates through REST APIs covering platform administration, dashboards, widgets, users, groups, data models, and related analytics operations. Token-based authentication is the usual server-to-server pattern, with permissions governed by the Sisense account and deployment. Selected products or configurations may provide notification or alert-style outbound mechanisms, but universal webhooks are not confirmed. Model refreshes and exports may require asynchronous status polling, while direct access to internal Sisense storage should not be assumed. Martini can consume these APIs, schedule incremental synchronization, receive applicable callbacks, map and validate responses, orchestrate refresh jobs, and expose controlled APIs for downstream applications.

Integration pointSupported by Sisense?Common use casesHow Martini supports it
REST APIsYesManage or retrieve Sisense dashboards, widgets, users, groups, data models, administration resources, and related platform metadata. Exact endpoints vary by deployment and version.Martini can consume Sisense REST endpoints from workflows, handle pagination and authentication, transform responses, and expose a controlled REST façade.
AuthenticationYesSisense REST integrations commonly authenticate through a Sisense authentication endpoint and use a bearer token on subsequent requests. Permissions follow the Sisense account.Martini can store credentials and token configuration in secrets or environment configuration and invoke authenticated API workflows without embedding secrets.
Webhooks / outbound callbacksLimitedNotification or alert-specific outbound mechanisms may be available in particular Sisense products or configurations, but universal object-level webhook coverage was not confirmed.Martini can receive a confirmed Sisense callback through an API endpoint and trigger downstream workflows; otherwise it can use scheduled polling.
Bulk / async / batch APIsLimitedModel refreshes, exports, and other long-running operations may return a job or status response. A universal bulk API for all Sisense objects was not confirmed.Martini can start an operation, capture its identifier, poll with bounded retries, and route timeout or failure states.
File / attachment APIsLimitedSisense supports export-oriented analytical content in applicable deployments, but a general-purpose attachment API was not confirmed.Martini can retrieve a documented export response and deliver the resulting file or payload to an approved destination.
Database / analytics accessLimitedSisense connects to external sources and provides analytical data-model access, but direct access to internal Sisense storage should not be assumed.Martini can connect to permitted source databases through JDBC and use Sisense APIs for model, dashboard, widget, and platform metadata.
GraphQL APIsNot confirmedA general-purpose Sisense GraphQL API was not confirmed in the reviewed sources.Martini can consume GraphQL when a documented target endpoint exists, but a Sisense GraphQL integration should be verified before design.
SOAP APIsNoNo current Sisense SOAP API was confirmed; new integrations should use documented REST or other supported interfaces.Martini supports SOAP consumption generally, but SOAP is not an appropriate confirmed Sisense mechanism for this page.

How Sisense exposes data and business events

Sisense REST APIs

Sisense REST APIs provide the primary integration mechanism for platform administration, dashboards, widgets, users, groups, data models, and related operations. Available paths and permissions depend on the Sisense edition, deployment model, and version.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates against the configured Sisense endpoint, calls the required REST resources, handles pagination and response validation, maps the result to a canonical model, and writes to the target system or exposes a controlled Martini API.

Implementation sequence

Authenticate with the Sisense endpoint
Retrieve the required Sisense resource pages
Validate permissions and response fields
Map the response to the target model
Write the result and record the synchronization outcome

Sisense notification callbacks

Some Sisense products or configurations may provide notification or alert-related outbound mechanisms. A universal webhook facility for all Sisense objects and lifecycle events was not confirmed.

Martini implementation pattern

Martini implementation pattern: where a supported Sisense callback exists, Martini exposes a secured API endpoint, validates the notification, retrieves current Sisense state through REST when necessary, and prevents duplicate processing. Scheduled polling remains the fallback when no suitable callback exists.

Implementation sequence

Receive the confirmed Sisense notification
Validate the callback and event context
Retrieve the current Sisense resource when required
Apply idempotency and business rules
Write the downstream result and acknowledge processing

Sisense asynchronous operations

Model refreshes, exports, and related analytics operations may be long-running and may return an operation or status response. A general-purpose bulk API was not confirmed.

Martini implementation pattern

Martini implementation pattern: a workflow starts the documented operation, stores its identifier, polls the status endpoint with bounded backoff, and branches to success, timeout, or failure handling before notifying dependent systems.

Implementation sequence

Start the documented Sisense operation
Store the returned operation identifier
Poll the operation status at bounded intervals
Apply timeout and failure rules
Publish completion or failure to the dependent system

Sisense source database access

Sisense uses external data sources and analytical models, but direct access to internal Sisense storage should not be assumed. Where permitted, source databases can be integrated separately from Sisense metadata APIs.

Martini implementation pattern

Martini implementation pattern: Martini reads approved source data through JDBC or another documented interface, transforms it for the analytical source model, and coordinates the resulting load with Sisense model refresh operations.

Implementation sequence

Connect to the approved source database
Retrieve incremental source data
Map and validate analytical fields
Deliver data through the approved loading process
Trigger and monitor the related Sisense refresh

Common Sisense integration patterns

Pattern 1: Publish Sisense dashboard metadata

When to use this pattern

Use this pattern when a catalog, governance repository, or internal API needs an inventory of Sisense dashboards, widgets, ownership, and sharing metadata. It is useful for discovery and access reviews without exposing Sisense directly to every consuming application.

Integration direction
Sisense
Martini
Metadata repository
Example Mapping
Sisense FieldCanonical FieldTarget Field
dashboard.oidanalyticsAssetIdasset_id
dashboard.titleassetNamename
dashboard.ownerownerReferenceowner
widget.typevisualizationTypecomponent_type
Martini implementation pattern

A scheduled Martini workflow retrieves paginated dashboards and nested widgets through the Sisense REST API, enriches them with approved user or group information, compares stable identifiers, and upserts the metadata. Per-object permission failures are recorded without silently discarding the rest of the scan; retries and checkpoints support repeatable synchronization.

Martini capabilities used
  • workflows
  • API consumption
  • scheduling
  • data mapping
  • business rules
  • error handling

Pattern 2: Refresh Sisense models after source loads

When to use this pattern

Use this pattern when an ERP, CRM, warehouse, or database load must be followed by a Sisense model or ElastiCube refresh. It separates source-data completion from analytics availability and gives operations a clear refresh outcome.

Integration direction
Source system
Martini
Sisense
Example Mapping
Sisense FieldCanonical FieldTarget Field
sourceLoad.statusloadCompletionStaterefreshPrecondition
model.identifieranalyticsModelIdmodelId
operation.statusrefreshStaterefreshStatus
operation.completedAtcompletionTimestampcompletedAt
Martini implementation pattern

Martini receives or detects source-load completion, validates that the load is eligible, invokes the documented Sisense refresh operation, and polls its status when supported. It applies concurrency and duplicate-request rules, uses bounded retries, and sends failure or timeout notifications to an operational destination.

Martini capabilities used
  • workflow orchestration
  • API consumption
  • conditional routing
  • polling
  • business rules
  • error handling

Pattern 3: Distribute Sisense analytical exports

When to use this pattern

Use this pattern when approved dashboard or widget exports must be delivered to an email process, file destination, document repository, or downstream API. It is appropriate only where the target Sisense deployment exposes a documented export operation.

Integration direction
Sisense
Martini
External destination
Example Mapping
Sisense FieldCanonical FieldTarget Field
dashboard.oidanalyticsAssetIdsourceAssetId
export.formatrequestedFormatfileFormat
export.contentgeneratedPayloadfileContent
export.createdAtgenerationTimestampcreatedAt
Martini implementation pattern

A Martini workflow requests the documented export, waits for completion when rendering is asynchronous, validates the response and file size, then delivers the output to the approved destination. It applies retention and access rules, avoids logging analytical content, and routes expired URLs, permission errors, or timeouts to retry or exception handling.

Martini capabilities used
  • workflows
  • API consumption
  • asynchronous orchestration
  • file handling
  • validation
  • error handling

Pattern 4: Synchronize Sisense users and groups

When to use this pattern

Use this pattern when identity or HR data must be reconciled with Sisense platform access. It supports controlled provisioning, group membership changes, and deprovisioning subject to the integration account's Sisense permissions.

Integration direction
Identity or HR system
Martini
Sisense
Example Mapping
Sisense FieldCanonical FieldTarget Field
employee.emailuserEmailemail
employee.activeaccountStateactive
group.externalIdaccessGroupIdgroupIdentifier
membership.userIduserReferencegroupMember
Martini implementation pattern

Martini retrieves approved identity data, compares stable Sisense identifiers and current memberships, and applies only necessary changes through administrative REST APIs. Validation, least-privilege rules, idempotent updates, audit logging, and isolated per-user or per-group failures make the reconciliation safe to rerun.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • business rules
  • idempotency
  • audit and error handling

Applications commonly integrated with Sisense

Sisense is commonly positioned alongside operational applications and analytical data platforms. These integrations typically move governed source data into Sisense models or use Sisense metadata and analytics outputs in downstream workflows; exact connectivity depends on the Sisense deployment and the source application's approved interfaces.

Application Scenario Direction Martini Pattern
Salesforce Combine accounts, opportunities, pipeline, and activity data with Sisense dashboards and analytics. Salesforce → Martini → Sisense Martini retrieves approved Salesforce data through the available source interface, maps it to a Sisense model or ingestion process, validates required fields, and schedules incremental synchronization with retry handling.
ServiceNow Analyze incidents, requests, changes, and service performance through Sisense dashboards. ServiceNow → Martini → Sisense A Martini workflow retrieves ServiceNow data, normalizes timestamps and reference fields, applies incremental-selection rules, and delivers the result to the approved Sisense data-loading or source-data process.
Jira Report on projects, issues, sprint progress, and engineering delivery metrics in Sisense. Jira → Martini → Sisense Martini extracts Jira project and issue data, transforms statuses and nested fields into an analytics-ready structure, validates changes, and invokes the target Sisense loading process.
Snowflake Use governed warehouse data as a source for Sisense analytical models and dashboards. Snowflake → Martini → Sisense Martini coordinates warehouse readiness with Sisense model refresh operations, polls long-running status responses when available, and routes refresh failures for operational handling.
Microsoft SQL Server Provide operational or reporting database data for Sisense models and dashboards. Microsoft SQL Server → Martini → Sisense Martini can read permitted SQL Server data through JDBC, apply incremental queries and canonical mappings, and invoke or monitor the corresponding Sisense model refresh.
Amazon Redshift Analyze cloud warehouse data through Sisense dashboards and embedded analytics. Amazon Redshift → Martini → Sisense A scheduled Martini workflow coordinates Redshift data availability with Sisense refresh operations, records operation identifiers, and applies bounded polling and retry policies.
NetSuite Combine financial, customer, order, and inventory information with other Sisense analytics sources. NetSuite → Martini → Sisense Martini retrieves approved NetSuite extracts or API data, maps financial and operational fields into the analytical source model, validates totals, and schedules delivery to Sisense.
Workday Provide workforce, organizational, and financial reporting through Sisense. Workday → Martini → Sisense Martini consumes an approved Workday API or reporting extract, normalizes organizational and effective-date fields, and delivers validated data to the Sisense ingestion or model-refresh process.

How to build a Sisense integration in Martini

Objective

Establish the Sisense API connection for the target edition and deployment while keeping account credentials and token configuration outside workflow payloads.

Instructions in Martini

  • Confirm the Sisense edition, version, base URL, and required API permissions
  • Configure the authentication endpoint and bearer-token behavior
  • Store credentials and environment-specific values in Martini secrets or secure configuration
  • Use a dedicated least-privilege integration account

Objective

Select an event, schedule, or upstream completion signal that matches the Sisense operation and its availability in the target deployment.

Instructions in Martini

  • Use a Sisense notification only when the product and configuration document the required callback
  • Use a scheduler for metadata synchronization or incremental polling
  • Use an upstream source-load completion signal before model refreshes
  • Define deduplication and checkpoint rules for repeatable execution

Objective

Call the required Sisense REST resources or approved source interface and collect complete results without assuming that a single response contains all objects.

Instructions in Martini

  • Call the documented REST endpoint for dashboards, widgets, users, groups, or models
  • Implement explicit pagination and termination conditions
  • Capture operation identifiers for refreshes and exports
  • Handle per-object permissions and partial response failures

Objective

Coordinate API calls, dependent operations, polling, conditional branches, and downstream writes in a maintainable Martini workflow.

Instructions in Martini

  • Separate authentication, retrieval, transformation, and delivery stages
  • Poll long-running operations with bounded intervals and timeouts
  • Apply concurrency controls around model refreshes
  • Route success, retryable failure, and terminal failure outcomes separately

Objective

Transform Sisense responses into stable canonical structures and validate fields that may vary across releases or deployment models.

Instructions in Martini

  • Map stable Sisense identifiers to canonical keys
  • Normalize nested widget, ownership, group, and timestamp fields
  • Validate required fields and expected response shapes
  • Version mappings when Sisense API or object schemas change

Objective

Apply business and security rules before changing Sisense resources or distributing analytical content.

Instructions in Martini

  • Compare current and desired state before issuing updates
  • Enforce least-privilege and approved group membership rules
  • Prevent duplicate refreshes and duplicate exports
  • Apply retention and sensitivity rules to generated analytical files

Common Sisense data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
DashboardsCollections of visualizations and filters used to present analytics; commonly synchronized for cataloging, governance, or export workflows.ServiceNow, internal metadata repositories, document repositories, email, downstream APIsMartini retrieves dashboard metadata through REST APIs, follows pagination, maps ownership and sharing fields, and handles inaccessible or deleted dashboards as per-object outcomes.
WidgetsIndividual charts, tables, KPI visualizations, and other dashboard components used for metadata synchronization or export-oriented workflows.Metadata repositories, governance systems, file destinations, downstream APIsMartini maps nested widget configuration into a canonical model, validates schema-sensitive fields, and records API-version differences or inaccessible objects.
ElasticubesSisense analytical data models used by dashboards and widgets, including refresh-related operations.Sisense refresh workflows, operations platforms, notification systemsMartini invokes documented refresh operations where available, stores operation identifiers, polls status, applies timeouts, and prevents duplicate refresh requests.
Data modelsAnalytical models that may represent ElastiCube or live-query data sources depending on deployment.Sisense, data warehouses, operational monitoring systemsMartini coordinates source-data readiness with model operations, maps model metadata, and routes refresh or validation failures for review.
UsersSisense platform users with permissions to access dashboards, models, and administrative resources.Identity platforms, HR systems, audit repositories, SisenseMartini compares stable identifiers and approved attributes, applies least-privilege update rules, supports deprovisioning workflows, and records audit results.
GroupsPermission and access-control groups used to manage users and shared Sisense content.Identity platforms, HR systems, governance repositories, SisenseMartini synchronizes membership and ownership changes idempotently, validates permissions, and isolates failures for individual groups or members.

Authentication and security considerations

Token-based API access

Sisense REST integrations commonly authenticate against a Sisense authentication endpoint and use a bearer token for subsequent requests. The exact endpoint, token lifetime, and permissions depend on the deployment and version.

Permissions and least privilege

API access follows the Sisense user's permissions for dashboards, widgets, data models, users, groups, and administrative resources. Use a dedicated account with only the permissions required by each workflow.

Secrets and sensitive data

  • Store credentials, tokens, and environment-specific endpoints in Martini secrets or secure configuration.
  • Do not embed credentials in workflow definitions or log bearer tokens.
  • Treat exported analytical content as potentially sensitive and apply retention and access controls.
  • Verify enterprise SSO and identity-provider arrangements separately from the server-to-server API authentication flow.

Operational considerations for Sisense integrations

Version and schema variation

Sisense API paths, authentication behavior, object models, and administrative operations can differ across Cloud, Linux, Windows, and older deployments. Version mappings and response validation should be maintained explicitly.

Pagination and throttling

Collection endpoints should use explicit pagination and termination conditions. Respect deployment-specific throttling and avoid large metadata scans during model refresh activity.

Long-running operations

Refreshes and exports may require polling, bounded retries, exponential backoff where appropriate, timeout limits, and a final failed state for operations that do not complete.

Idempotency and observability

  • Use stable Sisense identifiers and compare current state before updates.
  • Capture operation identifiers, response status, correlation information, and object identifiers.
  • Handle inaccessible dashboards or widgets as per-object failures rather than silently dropping them.
  • Keep passwords, bearer tokens, and sensitive analytical content out of logs.

Why use Martini instead of scripts or point-to-point integrations?

Orchestration beyond a script

Martini coordinates authentication, pagination, transformation, conditional routing, asynchronous polling, downstream delivery, and failure handling in maintainable workflows rather than scattering logic across point-to-point scripts.

Reusable integration assets

Teams can expose controlled APIs, reuse workflow logic, version mappings, and apply consistent business rules across dashboard metadata, model refresh, export, and access-synchronization processes.

Operational control

  • Schedule incremental synchronization and coordinate source loads with Sisense refreshes.
  • Centralize retries, timeout handling, validation, and per-object error reporting.
  • Keep credentials and deployment configuration separate from implementation logic.
  • Provide a stable API façade when downstream applications should not depend directly on Sisense version-specific endpoints.

Frequently asked questions

How can Sisense be integrated with enterprise systems?

Sisense can be integrated primarily through its REST APIs for dashboards, widgets, users, groups, data models, administration, and related platform resources. Depending on the deployment, selected notification mechanisms may support event-style processing, while scheduled API retrieval is the general fallback. Model refreshes and exports may require asynchronous status polling.

Can Martini integrate with Sisense?

Yes. Martini can consume documented Sisense REST APIs, authenticate using the deployment's token-based API pattern, orchestrate scheduled or event-driven workflows, transform Sisense data, and expose controlled APIs for downstream applications. A product-specific callback can also be received where Sisense documents one for the target configuration.

Do I need a connector to integrate Sisense with Martini?

No. A dedicated Sisense connector is not required. Martini can integrate using Sisense's documented REST APIs, token authentication, applicable notification callbacks, scheduled workflows, and approved source database interfaces.

Is there any extra Lonti cost to integrate Sisense with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Sisense. The integration uses the provisioned capacity of the Martini environment. Separate costs may apply from Sisense, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.

Which Sisense integration method should a new implementation use?

The Sisense REST API is the primary recommended method for platform resources, dashboards, widgets, users, groups, data models, and documented administrative operations. Confirm the exact endpoints, authentication flow, and permissions for the target Sisense edition and version before implementation.

Can Martini receive Sisense webhook or event notifications?

Only where the target Sisense product and configuration expose a supported notification or webhook mechanism. Universal webhooks for every Sisense object and lifecycle event were not confirmed, so scheduled polling and incremental comparison should be used when the required event is unavailable.

How should Sisense synchronization and model refreshes work?

Synchronization should use stable Sisense identifiers, explicit pagination, incremental selection where available, and comparison before updates. Model refreshes should be treated as potentially long-running: Martini can start the operation, capture its identifier, poll status with bounded retries, apply a timeout, and route failures to operations.

Can Martini expose an API façade for Sisense?

Yes. Martini can expose a controlled REST API that hides Sisense authentication details, applies business and authorization rules, normalizes responses, and gives downstream applications a stable contract while Sisense versions or endpoint details change.

Related Martini documentation

APIs

Workflows

Transformation

Security

Operations

Integrate Sisense with Martini

Use Martini to connect Sisense REST APIs and approved source systems through secure, observable workflows for analytics synchronization, model refreshes, exports, and platform administration.

EXPLORE MARTINI
BOOK A DEMO