Ellipse Gradient for Header

Sigma Computing Integration Guide

Integrate Sigma Computing with enterprise systems through REST APIs, scheduled workflows, selective automation features, and analytical exports.

Sigma Computing integration options at a glance

Sigma Computing’s primary programmatic integration mechanism is its REST API, which supports platform and administrative operations involving Workbooks, Datasets, Connections, Users, Teams, and selected exports. Sigma uses API clients and bearer access tokens for authentication. Selected action and automation features may provide callback-style behavior, but broad webhook coverage for all object changes is not confirmed, so scheduled polling is the safer synchronization pattern. Export operations can be asynchronous and may produce CSV, Excel, PDF, or image files where supported. Martini can orchestrate these calls, map JSON, poll long-running operations, deliver files, and expose a controlled API façade.

Integration pointSupported by Sigma Computing?Common use casesHow Martini supports it
REST APIsYesManage or retrieve platform and administrative resources such as Users, Teams, Workbooks, Datasets, Connections, and supported export operations.Martini can consume Sigma REST endpoints from workflows, send JSON requests, map responses, apply rules, and expose a separate REST API for downstream consumers.
AuthenticationYesSigma API clients authenticate with bearer access tokens, with permissions varying by resource and tenant configuration.Martini can store client credentials and tokens in secrets or environment configuration and attach authorization headers to API requests.
Webhooks / outbound callbacksLimitedSelected Sigma actions and automation features may support notifications or destinations, but broad object-change webhook coverage is not confirmed.Martini can receive a documented callback when the selected Sigma feature supports one; otherwise it can use scheduled polling workflows.
Bulk / asynchronous operationsLimitedExports and other long-running operations may require submission, status polling, and later retrieval; general bulk create or update support varies by endpoint.Martini can persist operation identifiers, poll with backoff, enforce timeouts, and handle completion or failure idempotently.
File and export operationsLimitedSelected workbooks or visualizations can be exported in formats such as CSV, Excel, PDF, or images where enabled by the operation.Martini can retrieve completed files, validate formats, stage or deliver them to downstream systems, and prevent duplicate delivery.
Database / analytics accessLimitedSigma connects to external warehouses and presents analytical data through Workbooks and Datasets; it is not a conventional transactional database endpoint.Martini can connect directly to the underlying warehouse using an appropriate database mechanism and use Sigma REST APIs for Sigma-specific metadata.
GraphQL APIsNot confirmedNo official Sigma GraphQL API was confirmed in the research.Martini should use Sigma REST APIs or documented export and automation mechanisms instead of assuming GraphQL support.
SOAP APIsNoNo official Sigma SOAP API was confirmed or recommended.Martini should not design a Sigma integration around SOAP.

How Sigma Computing exposes data and business events

Sigma REST APIs

Sigma’s documented REST APIs provide the primary integration surface for platform and administrative operations. Availability of resources and operations depends on the API version, tenant configuration, and API client permissions.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with a Sigma API client, calls the required endpoint, validates the JSON response, maps Sigma objects to a canonical model, and writes the result to a target system or returns it through a Martini API.

Implementation sequence

Authenticate with a Sigma API client and bearer access token
Call the required Sigma REST endpoint
Validate the response and pagination state
Map Sigma JSON into the target model
Apply business rules and write the result
Record identifiers, status, and audit information

Sigma Actions and callbacks

Sigma has selected action and automation capabilities, but a general-purpose webhook API covering every Workbook, Dataset, Connection, User, or Team change was not confirmed.

Martini implementation pattern

Martini implementation pattern: use a callback only when the selected Sigma feature explicitly documents the event and destination; otherwise replace the event trigger with scheduled polling and durable state comparison.

Implementation sequence

Verify that the selected Sigma feature documents the required callback
Receive and validate the notification when available
Retrieve the current Sigma resource if the notification is incomplete
Map and process the resource idempotently
Record the event or polling checkpoint
Use scheduled reconciliation for missed or unsupported events

Asynchronous exports

Selected Sigma export operations can produce files asynchronously. A reliable implementation may need to submit an operation, poll its status, retrieve the completed file, and account for temporary download URL expiration.

Martini implementation pattern

Martini implementation pattern: the workflow submits an export, persists the Sigma operation identifier, polls with controlled backoff, downloads the file after completion, and delivers it only once to the configured destination.

Implementation sequence

Submit the supported Sigma export request
Persist the operation identifier and requested object
Poll the operation with backoff
Stop when the operation completes or times out
Download and validate the resulting file
Deliver the file and record the completion state

Scheduled metadata synchronization

Because broad event coverage was not confirmed, scheduled polling is the safer default for synchronizing Workbooks, Datasets, Connections, Users, and Teams.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a workflow that retrieves paginated Sigma resources, compares them with a durable local state or target catalog, applies creates and updates, detects removals, and records the checkpoint.

Implementation sequence

Start the scheduled synchronization workflow
Retrieve Sigma resources page by page
Normalize and compare current state
Apply idempotent creates, updates, and deactivations
Persist the checkpoint and identifier mappings
Report failures and retry transient requests

Common Sigma Computing integration patterns

Pattern 1: Provision Sigma users and teams

When to use this pattern

Use this pattern when an identity or HR system controls Sigma access. Martini receives or retrieves lifecycle changes, maps users and groups to Sigma Users and Teams, and applies idempotent provisioning and deactivation rules.

Integration direction
Identity or HR system
Martini
Sigma Computing
Example Mapping
Sigma Computing FieldCanonical FieldTarget Field
emailuser.emailSigma User email
displayNameuser.displayNameSigma User display name
group membershipteam.membershipSigma Team membership
Martini implementation pattern

A Martini workflow retrieves source changes, looks up existing Sigma identifiers, validates required attributes, and calls Sigma REST endpoints. It records mappings and outcomes so retries do not create duplicate Users or Teams, and it deactivates access according to policy rather than assuming deletion is appropriate.

Martini capabilities used
  • workflows
  • API consumption
  • OAuth 2.0 configuration
  • data mapping
  • business rules
  • error handling

Pattern 2: Distribute scheduled Sigma exports

When to use this pattern

Use this pattern when business users need recurring workbook or visualization outputs in a controlled destination such as SFTP, object storage, email, or a document repository.

Integration direction
Martini Scheduler
Sigma Computing
Martini
SFTP or object storage
Example Mapping
Sigma Computing FieldCanonical FieldTarget Field
workbook identifierreport.sourceIdexport request resource
export formatreport.formatSigma export format
completed filereport.binaryContentdestination file object
Martini implementation pattern

A scheduled Martini workflow submits the supported export request, persists the operation identifier, polls with backoff, retrieves the file, validates its format and naming rules, and delivers it once. Timeout, expired URL, duplicate delivery, and downstream availability failures are routed through retry and audit logic.

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

Pattern 3: Synchronize Sigma metadata to governance

When to use this pattern

Use this pattern when a data catalog, governance platform, or ITSM process needs visibility into Sigma Workbooks, Datasets, Connections, Users, or Teams.

Integration direction
Sigma Computing
Martini
Data catalog or ServiceNow
Example Mapping
Sigma Computing FieldCanonical FieldTarget Field
Sigma object idasset.externalIdcatalog external identifier
nameasset.namecatalog name
owner or access informationasset.governanceMetadataownership and access fields
Martini implementation pattern

A scheduled Martini workflow retrieves paginated resources, normalizes Sigma-specific fields, compares them with a durable mapping store, and applies creates, updates, or deactivations. Full reconciliation can run less frequently, while incremental polling runs more often when suitable timestamps or filters are available.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination handling
  • data mapping
  • SQL persistence
  • business rules

Pattern 4: Coordinate warehouse readiness with Sigma operations

When to use this pattern

Use this pattern when a warehouse refresh or governed data publication should trigger a Sigma-related export, notification, or downstream process, subject to the specific Sigma operation supported by the tenant.

Integration direction
Data platform or orchestration system
Martini
Sigma Computing
Downstream application
Example Mapping
Sigma Computing FieldCanonical FieldTarget Field
refresh completiondataProduct.statusworkflow entry condition
Sigma resource identifieranalytics.resourceIdSigma API path or request
operation statusanalytics.operationStatusdownstream notification state
Martini implementation pattern

Martini receives or polls the data-readiness status, validates that the required Sigma resource and operation are supported, then invokes Sigma through REST APIs. It tracks correlation identifiers and operation status, avoids assuming that every object can be refreshed, and notifies the downstream application only after confirmed completion.

Martini capabilities used
  • API orchestration
  • workflows
  • conditional routing
  • data validation
  • business rules
  • monitoring

Applications commonly integrated with Sigma Computing

Sigma is commonly used as an analytics layer over cloud data platforms, while enterprise applications often contribute source data or consume selected reports and metadata. Martini can coordinate these flows without treating Sigma as a transactional database or assuming a direct native connector.

Application Scenario Direction Martini Pattern
Snowflake Sigma can use Snowflake as a governed warehouse source for workbooks and analytical reporting. Snowflake → Sigma Computing Use Martini to coordinate warehouse publication or metadata workflows, and use Sigma REST APIs for Sigma-specific operations. For high-volume data movement, connect Martini to Snowflake rather than repeatedly exporting large Sigma views.
Databricks Databricks data can support lakehouse-backed Sigma analysis while Databricks remains the data platform. Databricks → Sigma Computing Coordinate data readiness from Databricks or its surrounding orchestration layer, then invoke documented Sigma operations through a Martini workflow when reporting or export activity should follow.
Google BigQuery BigQuery can provide governed analytical data for Sigma workbooks and reporting. Google BigQuery → Sigma Computing Use Martini for orchestration, status tracking, and downstream delivery while keeping analytical extraction at the warehouse layer where appropriate.
Salesforce Salesforce data can be combined with warehouse data in Sigma for pipeline, account, and revenue analysis. Salesforce → Data warehouse → Sigma Computing Ingest or coordinate Salesforce data through the enterprise data pipeline, then use Martini to synchronize relevant Sigma metadata or distribute approved exports.
Slack Selected Sigma outputs or report notifications can be distributed to collaboration channels when the relevant feature supports that destination. Sigma Computing → Martini → Slack Use Martini to retrieve a completed export, apply delivery rules, and send a controlled notification or file to Slack through its supported API, without assuming Sigma provides a general Slack integration.
ServiceNow Sigma analytics and metadata can support operational reporting and governance processes associated with ServiceNow. Sigma Computing → Martini → ServiceNow Poll Sigma metadata or retrieve an approved export, map it to ServiceNow records or workflow inputs, and apply idempotent updates with audit logging.
Jira Jira delivery data can be combined with business metrics in warehouse-backed Sigma reporting. Jira → Data warehouse → Sigma Computing Use Martini to coordinate source-data or report-readiness workflows and invoke Sigma REST operations for metadata, exports, or downstream distribution.
NetSuite NetSuite finance and operational data can be loaded into a warehouse and analyzed alongside other sources in Sigma. NetSuite → Data warehouse → Sigma Computing Keep high-volume financial extraction at the source or warehouse layer, then use Martini for Sigma metadata synchronization, export orchestration, and controlled delivery.

How to build a Sigma Computing integration in Martini

Objective

Establish a controlled connection to the customer’s Sigma tenant using the appropriate regional API host and a dedicated API client.

Instructions in Martini

  • Confirm the regional Sigma API hostname and tenant configuration
  • Create or obtain an appropriately scoped Sigma API client
  • Store credentials and tokens in Martini secrets or environment configuration
  • Configure bearer-token authorization without exposing secrets in logs

Objective

Select an event, callback, API entry point, or schedule based on the confirmed Sigma feature and synchronization requirements.

Instructions in Martini

  • Use a documented Sigma callback only for the specific supported feature and event
  • Use a Scheduler Trigger for metadata reconciliation when broad events are unavailable
  • Expose a Martini REST API when an internal application should initiate the operation
  • Define the polling interval and checkpoint strategy

Objective

Call Sigma REST endpoints or initiate an export while handling pagination, permissions, and asynchronous status.

Instructions in Martini

  • Retrieve the required Workbooks, Datasets, Connections, Users, or Teams
  • Preserve pagination cursors or tokens exactly as returned
  • Persist export operation identifiers before polling
  • Apply controlled backoff and timeout rules for long-running operations

Objective

Coordinate Sigma calls, local state, target-system actions, and conditional branches in a maintainable Martini workflow.

Instructions in Martini

  • Validate request and response structures
  • Use durable state for identifiers, checkpoints, and operation status
  • Branch on authorization, throttling, validation, and completion outcomes
  • Keep Sigma-specific logic in reusable workflow assets

Objective

Convert Sigma JSON and export metadata into canonical models or downstream payloads while preserving important identifiers.

Instructions in Martini

  • Map vendor fields to the canonical integration model
  • Normalize dates, statuses, names, and access attributes
  • Apply required transformations for target APIs or files
  • Validate required fields before writing to the target

Objective

Enforce enterprise access, delivery, retention, and reconciliation policies before changing Sigma or downstream systems.

Instructions in Martini

  • Apply least-privilege and deactivation rules for Users and Teams
  • Prevent duplicate export delivery with durable state
  • Restrict report destinations based on data classification
  • Detect removed, renamed, or disabled resources during reconciliation

Common Sigma Computing data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
WorkbooksAnalytical documents containing worksheets, visualizations, controls, and related analysis.Data catalogs, governance platforms, ITSM systems, file repositoriesMartini retrieves documented workbook metadata, maps identifiers and ownership fields, and can orchestrate supported exports.
DatasetsReusable analytical data assets used to support workbook development and governed reporting.Data catalogs, governance platforms, warehouse metadata storesMartini polls and reconciles dataset metadata, validates response fields, and stores durable mappings to target objects.
ConnectionsConfigured links between Sigma and external data platforms such as cloud warehouses.Governance platforms, configuration inventories, ITSM systemsMartini synchronizes connection metadata without treating Sigma connections as a replacement for direct warehouse access.
UsersIndividual Sigma identities that may be provisioned, updated, deactivated, or associated with Teams.Identity platforms, HR systems, ITSM systemsMartini performs idempotent lookups and updates, applies least-privilege rules, and records Sigma identifiers and status.
TeamsGroups used to organize Users and manage access.Identity platforms, HR systems, governance platformsMartini maps source groups to Sigma Teams, reconciles membership, and handles retries without duplicating groups.
ExportsGenerated workbook or visualization outputs such as CSV, Excel, PDF, or image files where supported.SFTP, object storage, email, document repositories, reporting systemsMartini submits or retrieves export operations, polls asynchronous status, downloads files, and records durable delivery state.

Authentication and security considerations

API authentication

Sigma documents API clients and bearer access tokens for REST API authentication. The required permissions depend on the resource and operation, including tenant-level operations involving Users, Teams, Workbooks, or Connections.

Credential protection

  • Use a dedicated Sigma API client rather than personal credentials.
  • Store client credentials and tokens in Martini secrets or environment configuration.
  • Apply least-privilege permissions and rotate credentials according to enterprise policy.
  • Do not place access tokens, exported report contents, or sensitive payloads in workflow logs.

Tenant and data security

Confirm the customer’s regional API hostname and tenant configuration before deployment. Preserve Sigma permission boundaries when exposing operations through a Martini API and apply retention controls to exported files and temporary downloads.

Operational considerations for Sigma Computing integrations

Reliability and scale

  • Confirm Sigma rate limits and implement exponential backoff for throttling and transient failures.
  • Treat collection responses as paginated unless the endpoint explicitly states otherwise.
  • Persist operation identifiers and poll asynchronous exports with a controlled interval and timeout.
  • Use Sigma object identifiers and durable mappings to make retries idempotent.

Change management

Avoid undocumented response fields, validate required fields, tolerate additive fields, and monitor Sigma API release and deprecation information. Test representative tenant configurations, export formats, permissions, and download URL behavior before production deployment.

Observability

Log correlation identifiers, endpoint names, status codes, workflow execution identifiers, checkpoints, and operation states without logging credentials or sensitive report contents. Reconcile missed or unsupported events through scheduled polling.

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

Beyond point-to-point scripts

Martini provides a maintainable workflow layer around Sigma REST APIs, scheduled polling, asynchronous exports, and downstream delivery. This separates authentication, vendor-specific mappings, business rules, retries, and operational state from individual scripts.

  • Expose a controlled Martini API instead of distributing Sigma credentials across applications.
  • Reuse mappings and orchestration for Users, Teams, metadata, and exports.
  • Apply consistent validation, idempotency, retries, timeout handling, and audit logging.
  • Coordinate Sigma with warehouses, governance systems, file destinations, and enterprise applications.

Appropriate system boundary

Use Sigma REST APIs for Sigma-specific administration and metadata. Use the underlying warehouse or database for high-volume analytical data access, avoiding unnecessary repeated exports through Sigma.

Frequently asked questions

How can Sigma Computing be integrated with enterprise systems?

Sigma Computing can be integrated primarily through its REST APIs for administrative and platform operations, including Workbooks, Datasets, Connections, Users, Teams, and selected exports. Enterprise solutions can also use scheduled polling, selected Sigma automation features, and supported CSV, Excel, PDF, or image exports. For high-volume analytical data movement, integrations should generally target the underlying warehouse rather than treating Sigma as a transactional database.

Can Martini integrate with Sigma Computing?

Yes. Martini can consume Sigma REST APIs, authenticate with API clients and bearer access tokens, synchronize Sigma metadata on a schedule, orchestrate supported exports, retrieve generated files, and expose a controlled API façade for internal applications. No native Martini Sigma connector is documented in the supplied research.

Do I need a connector to integrate Sigma Computing with Martini?

No. A dedicated Sigma connector is not required. Martini can integrate with Sigma using its confirmed REST APIs, bearer-token authentication, supported export operations, scheduled polling, and selected documented action or callback features.

Is there any extra Lonti cost to integrate Sigma Computing with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Sigma Computing. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Sigma, cloud infrastructure, data warehouses, storage, or other third-party services based on their pricing and usage.

Which Sigma integration methods should be used for new integrations?

Sigma REST APIs are the primary documented method for platform and administrative operations. Use API clients with bearer access tokens, scheduled workflows for reliable metadata synchronization, and supported export operations for report delivery. GraphQL and SOAP APIs were not confirmed for Sigma, and broad webhook coverage was not confirmed.

Does Sigma Computing provide webhooks or event notifications?

Sigma has selected action and automation capabilities, but a general-purpose webhook mechanism for every Workbook, Dataset, Connection, User, and Team change was not confirmed. Use a documented callback only for the specific feature and event; scheduled polling is the safer default for broad synchronization.

How does synchronization with Sigma Computing work?

Martini can run scheduled workflows that retrieve paginated Sigma resources, compare them with durable checkpoints or identifier mappings, and apply idempotent changes to a target catalog, governance platform, or ITSM system. Full reconciliation can run less frequently, with incremental polling used where suitable timestamps or filters are available.

How are Sigma data mapping, retries, and long-running exports handled?

Martini maps Sigma JSON into canonical and target models, validates required fields, applies business rules, and routes transient failures through controlled retries and backoff. For asynchronous exports, it persists the operation identifier, polls until completion or timeout, retrieves the file, and uses durable delivery state to prevent duplicates.