.png)
ThoughtSpot Integration Guide
Connect ThoughtSpot analytics, content, users, permissions, and data workflows with enterprise systems through REST APIs, data interfaces, TML exchanges, and secure orchestration.
ThoughtSpot integration options at a glance
ThoughtSpot’s primary integration mechanism is its REST API, which supports authentication, analytics, Answers, Liveboards, users, groups, permissions, metadata, and selected data operations. Analytics and data access APIs can export results for warehouses, operational systems, files, and business processes. TML and metadata interfaces support governed promotion between ThoughtSpot environments, while supported data-upload methods can be orchestrated for ingestion. Webhooks for universal object changes are not confirmed, so scheduled polling or documented callbacks may be more appropriate. Martini can securely manage authentication, paginate and transform responses, validate payloads, orchestrate workflows, and expose controlled APIs around ThoughtSpot operations.
| Integration point | Supported by ThoughtSpot? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Authenticate sessions, retrieve Answers and Liveboards, manage users, groups, permissions, metadata, analytics, and selected data operations. Confirm the supported API generation and endpoint family for the tenant. | Martini can consume ThoughtSpot REST APIs, manage request authentication, map responses, paginate results, apply business rules, and expose reusable APIs around the operations. |
| Analytics and data access APIs | Yes | Retrieve analytical results and export data from Answers or Liveboards for warehouses, operational systems, files, alerts, and business processes. | Martini can schedule retrieval, transform JSON or export payloads, validate result limits and freshness, and deliver approved data to downstream systems. |
| Authentication | Yes | Use session-based or bearer-token REST authentication, and use trusted authentication for supported embedded analytics scenarios. Exact options depend on deployment and configuration. | Martini can store secrets securely, acquire and reuse tokens, handle expiration and re-authentication, and keep trusted-authentication material server-side. |
| TML and metadata APIs | Yes | Represent and promote worksheets, tables, Answers, Liveboards, and related modeled content between ThoughtSpot environments where the applicable APIs are enabled. | Martini can retrieve TML or metadata, substitute environment-specific values, validate dependencies, submit changes, and record partial failures. |
| Bulk, asynchronous, or batch APIs | Limited | Selected data, metadata, or administrative operations may support bulk or asynchronous behavior. Job semantics, limits, and endpoint coverage require verification. | Martini can orchestrate request and status-check workflows, apply controlled concurrency, and retry transient failures when the target endpoint documents those behaviors. |
| File and data ingestion | Limited | CSV or other supported upload methods may support data loading, while exported ThoughtSpot data can be processed for downstream use. Formats and methods vary by deployment. | Martini can prepare, validate, transform, and deliver files or consume exports, while keeping deployment-specific upload assumptions explicit. |
| Scheduled synchronization | Yes | Scheduled polling can retrieve analytics, users, groups, metadata, or exports when a universal webhook model is unavailable or not confirmed. | Martini can use scheduler-triggered workflows, checkpoints, pagination, idempotent upserts, and monitoring to implement repeatable synchronization. |
| Webhooks and outbound callbacks | Not confirmed | A universal webhook framework for changes to Answers, Liveboards, users, groups, and data objects was not confirmed. Specific callbacks or surrounding-product notifications must be verified. | Martini can receive a confirmed callback through an exposed API, but should otherwise use scheduled polling or documented delivery mechanisms rather than assume universal webhooks. |
How ThoughtSpot exposes data and business events
ThoughtSpot REST APIs
ThoughtSpot’s REST APIs are the principal programmatic integration mechanism. They cover authentication, users, groups, permissions, analytics, Answers, Liveboards, metadata, and selected data operations, with exact endpoint availability depending on API generation and deployment.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to the configured ThoughtSpot endpoint, invokes the required REST operation, handles pagination and response limits, transforms the response, and writes or exposes the result through a controlled integration API.
Implementation sequence
Analytics and data access APIs
ThoughtSpot provides APIs for retrieving analytical results and exporting data from Answers or Liveboards. These capabilities support scheduled extracts, downstream alerts, warehouse delivery, and operational processing, subject to permissions and endpoint-specific limits.
Martini implementation pattern
Martini implementation pattern: a scheduled or API-triggered workflow requests an authorized analytical result, checks freshness and export constraints, converts JSON or CSV data into the target format, and delivers it to a database, file destination, or downstream API.
Implementation sequence
TML and metadata APIs
ThoughtSpot Modeling Language and metadata interfaces can support controlled movement of worksheets, tables, Answers, Liveboards, and related modeled content between environments. Dependencies and supported operations vary by API version and deployment.
Martini implementation pattern
Martini implementation pattern: a workflow retrieves TML or metadata from a source environment, applies controlled substitutions and validation, checks dependencies, submits the result to the target environment, and records deployment errors for remediation.
Implementation sequence
File and data ingestion
ThoughtSpot may support CSV or other data-upload methods, while exported analytical data can be consumed as files. Supported formats, upload behavior, and deployment-specific interfaces must be confirmed before implementation.
Martini implementation pattern
Martini implementation pattern: Martini prepares or receives a file, validates structure and business rules, transforms the content when required, delivers it through the confirmed ThoughtSpot data interface, and records the load result.
Implementation sequence
Scheduled synchronization
Because universal ThoughtSpot webhooks for object and data changes are not confirmed, scheduled polling is a practical mechanism for retrieving updated analytics, users, groups, metadata, or exports.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a workflow that retrieves changed or relevant data, uses stable identifiers and checkpoints, applies idempotent writes, and retries transient failures without duplicating downstream results.
Implementation sequence
Common ThoughtSpot integration patterns
Pattern 1: Export analytics to an operational system
When to use this pattern
Use this pattern when an organization needs approved metrics from a ThoughtSpot Answer or Liveboard in a finance, planning, operational, or reporting process. It is suitable for scheduled extracts where permissions, freshness, row limits, and downstream validation matter.
Integration direction
Example Mapping
| ThoughtSpot Field | Canonical Field | Target Field |
|---|---|---|
| Answer result identifier | analyticsResultId | source_result_id |
| Metric value | metricValue | metric_value |
| Result timestamp | observedAt | observed_at |
| Business dimension | dimensionValue | dimension_value |
Martini implementation pattern
A scheduler-triggered Martini workflow authenticates to ThoughtSpot, retrieves the authorized Answer or Liveboard result, handles pagination or asynchronous export behavior, normalizes JSON or CSV values, applies freshness and threshold rules, and performs an idempotent write to the operational database. Authentication failures, export limits, and transient API errors are routed to controlled error handling and retry paths.
Martini capabilities used
- workflows
- scheduled triggers
- API consumption
- data mapping
- business rules
- error handling
- monitoring
Pattern 2: Synchronize ThoughtSpot users and groups
When to use this pattern
Use this pattern when ThoughtSpot access must follow an identity, HR, or application entitlement source. The workflow can create, update, disable, or reassign ThoughtSpot users and groups using stable identity mappings and repeatable provisioning rules.
Integration direction
Example Mapping
| ThoughtSpot Field | Canonical Field | Target Field |
|---|---|---|
| Source user identifier | externalUserId | ThoughtSpot user identifier |
| Email address | ThoughtSpot user email | |
| Entitlement groups | groupMemberships | ThoughtSpot groups |
| Account status | active | ThoughtSpot user status |
Martini implementation pattern
Martini receives or polls identity changes, resolves stable identifiers, validates required attributes, and calls the supported ThoughtSpot administrative APIs. Business rules determine group membership and deactivation behavior. Idempotent upserts prevent duplicates, while authorization failures, invalid groups, and partial updates are logged for remediation.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- idempotency
- error handling
- audit logging
Pattern 3: Promote TML between ThoughtSpot environments
When to use this pattern
Use this pattern for governed promotion of worksheets, tables, Answers, Liveboards, or related modeled content from development or test into production. It is appropriate when environment-specific values and dependencies must be validated before submission.
Integration direction
Example Mapping
| ThoughtSpot Field | Canonical Field | Target Field |
|---|---|---|
| TML object name | assetName | productionAssetName |
| Source connection | sourceConnection | targetConnection |
| Worksheet dependency | worksheetDependency | productionWorksheetDependency |
| Environment parameter | environmentValue | productionEnvironmentValue |
Martini implementation pattern
A Martini workflow retrieves TML or metadata from the source environment, parses and validates the payload, substitutes approved target values, checks dependent tables and worksheets, and submits the content to the target ThoughtSpot API. The workflow records each asset outcome and separates retryable API failures from dependency or validation failures.
Martini capabilities used
- workflows
- API consumption
- data transformation
- validation
- business rules
- deployment orchestration
- error handling
Pattern 4: Orchestrate embedded analytics access
When to use this pattern
Use this pattern when an application embeds ThoughtSpot and requires server-side control over user authorization, groups, and trusted-authentication material. It keeps secrets and access decisions outside the browser-facing application.
Integration direction
Example Mapping
| ThoughtSpot Field | Canonical Field | Target Field |
|---|---|---|
| Application user ID | principalId | ThoughtSpot user identity |
| Application roles | entitlements | ThoughtSpot groups |
| Requested content | contentScope | Answer or Liveboard access |
| Trusted-authentication material | serverAuthContext | ThoughtSpot session or trusted-auth request |
Martini implementation pattern
Martini exposes a controlled API that accepts the host application identity, verifies authorization, maps entitlements to ThoughtSpot groups or access context, and performs the required server-side authentication flow. Secrets remain in secure environment configuration. The workflow returns only the data required by the host application and records denied or failed requests without exposing credentials.
Martini capabilities used
- API exposure
- workflows
- authentication and authorization
- secure configuration
- data mapping
- business rules
- error handling
Applications commonly integrated with ThoughtSpot
ThoughtSpot is commonly positioned alongside data platforms, enterprise applications, and operational systems. In many architectures, application data is first replicated into a supported warehouse or lakehouse before ThoughtSpot analyzes it. Martini can coordinate those upstream and downstream exchanges without assuming a direct native connector for each application.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Snowflake | Provide governed warehouse data to ThoughtSpot and deliver selected analytics or extracts to operational processes. | Snowflake → ThoughtSpot → Martini → Downstream applications | Martini can orchestrate warehouse-oriented extracts, call ThoughtSpot REST APIs for approved Answers or Liveboards, normalize analytical results, and deliver them to downstream workflows while preserving the permissions of the integration identity. |
| Amazon Redshift | Analyze Redshift data in ThoughtSpot and distribute selected metrics or extracts to business processes. | Amazon Redshift → ThoughtSpot → Martini → Business applications | A scheduled Martini workflow can coordinate source-data readiness, retrieve ThoughtSpot results, validate row and column content, transform the response, and write an approved extract to a target database or file destination. |
| Google BigQuery | Make governed BigQuery datasets available for search-driven analytics and use selected results in business workflows. | Google BigQuery → ThoughtSpot → Martini → Business workflows | Martini can manage scheduled retrieval from ThoughtSpot, map analytical fields to a canonical model, apply threshold or freshness rules, and invoke downstream APIs when the result meets the required conditions. |
| Databricks | Expose lakehouse data for ThoughtSpot analysis and use analytical outputs in operational or governance workflows. | Databricks → ThoughtSpot → Martini → Operational systems | Martini can coordinate data-load or export stages, call the applicable ThoughtSpot API, process JSON or CSV results, and route validated outputs to operational databases, files, or APIs. |
| Salesforce | Combine CRM data with warehouse or operational data for pipeline and customer analysis, then distribute approved metrics to related processes. | Salesforce → Data platform → ThoughtSpot → Martini | Where Salesforce data is replicated into a supported data platform, Martini can retrieve ThoughtSpot analytics, map customer or pipeline metrics, and send approved outcomes to Salesforce-related workflows or other enterprise endpoints. |
| ServiceNow | Analyze incidents, requests, and service operations in ThoughtSpot and distribute selected metrics to management or operational workflows. | ServiceNow → Data platform → ThoughtSpot → Martini | Martini can orchestrate scheduled analytics retrieval, validate service-management metrics, apply business rules, and expose or deliver the resulting data to ServiceNow-related processes. |
| Workday | Analyze workforce or finance data in a governed ThoughtSpot environment and use approved outputs in reporting or planning processes. | Workday → Data platform → ThoughtSpot → Martini | Martini can coordinate approved data exports or replicated data flows, retrieve ThoughtSpot results, normalize dates and numeric formats, and write controlled outputs to planning or reporting destinations. |
| Oracle | Combine Oracle application or database data with ThoughtSpot analytics and return approved extracts or metrics to downstream systems. | Oracle → ThoughtSpot → Martini → Downstream systems | Martini can call ThoughtSpot APIs for authorized analytical content, transform results into the target Oracle or enterprise schema, apply idempotent write rules, and record workflow outcomes. |
How to build a ThoughtSpot integration in Martini
Objective
Establish the ThoughtSpot endpoint, supported API version, authentication method, and target environment without embedding credentials in workflow logic.
Instructions in Martini
- Confirm the tenant base URL and REST API generation
- Choose the documented session, bearer-token, or trusted-authentication pattern
- Store credentials and secrets in secure Martini configuration
- Define the permitted Answers, Liveboards, users, groups, or data operations
Objective
Select an execution model that matches the availability of ThoughtSpot callbacks and the business freshness requirement.
Instructions in Martini
- Use a REST API trigger for on-demand requests
- Use a scheduler for polling, extracts, and synchronization
- Receive only specifically confirmed callbacks through an exposed API
- Define checkpoints or synchronization windows for recurring jobs
Objective
Call the appropriate ThoughtSpot REST, analytics, metadata, TML, or data interface and handle endpoint-specific response behavior.
Instructions in Martini
- Authenticate and obtain a valid session or bearer token
- Invoke the required ThoughtSpot operation
- Traverse pagination and monitor asynchronous jobs where documented
- Respect permissions, export limits, and source-data freshness
Objective
Coordinate the end-to-end process from retrieval through validation, transformation, delivery, and operational status handling.
Instructions in Martini
- Branch on authentication, authorization, validation, and transient API outcomes
- Use reusable workflow logic for token handling and common response processing
- Keep source and target environment configuration separate
- Persist checkpoints and correlation information
Objective
Convert ThoughtSpot JSON, CSV, TML, metadata, or administrative payloads into a stable canonical or target-specific model.
Instructions in Martini
- Map Answer, Liveboard, user, group, worksheet, or table fields explicitly
- Normalize timestamps, locale-sensitive values, and numeric formats
- Validate required fields and schema assumptions
- Apply environment-specific substitutions only through controlled rules
Objective
Enforce authorization, freshness, entitlement, dependency, threshold, and idempotency rules before changing downstream systems or ThoughtSpot environments.
Instructions in Martini
- Verify the integration identity is authorized for the requested content
- Apply stable identifiers for user, group, asset, and export processing
- Reject stale, incomplete, or out-of-scope results
- Separate retryable failures from validation and authorization failures
Common ThoughtSpot data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Answer | Represent a saved or generated analytical result based on a search or query; commonly retrieved for reporting, extracts, or downstream business decisions. | Data warehouses, operational databases, files, reporting processes, and business applications | Martini retrieves authorized Answers through the applicable REST or analytics API, maps result fields to a canonical model, validates freshness and limits, and routes the output. |
| Liveboard | Provide a dashboard-style collection of visualizations and analytical content for scheduled exports, management reporting, or embedded experiences. | Data warehouses, reporting repositories, files, email or messaging processes, and embedded applications | Martini can retrieve authorized Liveboard content or associated analytical results, transform exports, and deliver only the data permitted for the integration identity. |
| Visualization | Represent a chart, table, or other visual representation within an Answer or Liveboard. | Reporting stores, downstream analytics processes, files, and embedded application workflows | Martini can preserve relevant visualization metadata or extract its underlying result where the ThoughtSpot endpoint exposes it, while avoiding assumptions about unsupported visual formats. |
| Worksheet | Provide a modeled analytical data object with business-friendly columns and relationships for search and analytics. | ThoughtSpot environments, data platforms, metadata repositories, and deployment pipelines | Martini can use REST or TML-related workflows to validate, migrate, and environment-substitute worksheet definitions and dependencies. |
| Table | Represent a physical or logical data table available to ThoughtSpot analytics and data operations. | Data platforms, ThoughtSpot environments, metadata repositories, and ingestion workflows | Martini can coordinate supported data-loading or metadata operations, validate schemas, and account for dependencies when promoting or synchronizing table definitions. |
| User and group | Control access to ThoughtSpot content and data through identity mappings, sharing permissions, and group-based policies. | Identity platforms, HR systems, enterprise applications, and ThoughtSpot administration | Martini can implement idempotent provisioning and deprovisioning workflows, map stable identities, apply group rules, and record authorization outcomes. |
Authentication and security considerations
Authentication patterns
ThoughtSpot REST integrations may use session-based authentication or bearer tokens, while embedded analytics can use a trusted-authentication flow. The exact method depends on the ThoughtSpot deployment, API generation, and embedding configuration.
Credential protection
Martini should store session secrets, client secrets, trusted-authentication material, and environment-specific endpoints in secure configuration rather than workflow logic. Tokens and secrets should not be returned to browser clients or written to logs.
Authorization and data access
ThoughtSpot users, groups, sharing permissions, row-level controls, and data-access policies affect the results available to an integration identity. Workflows should request only authorized content and preserve those controls when exporting data.
- Confirm the supported authentication method for the target tenant.
- Use least-privilege identities for administrative, analytics, and embedding operations.
- Separate development, test, and production credentials and endpoints.
Operational considerations for ThoughtSpot integrations
API behavior
Confirm the REST API generation, endpoint limits, pagination model, export row and file limits, asynchronous job behavior, and token lifetime before implementation. Use controlled concurrency and retry transient failures with backoff.
Consistency and idempotency
User provisioning, group updates, TML promotion, and data loads should use stable identifiers and repeatable upsert logic. Persist checkpoints for scheduled polling and avoid reprocessing unchanged analytical content.
Schema and dependency changes
Worksheet columns, table names, Answer definitions, and TML structures can change. Validate required fields and dependencies, isolate environment-specific mappings, and test promotions against representative content.
Monitoring and troubleshooting
- Distinguish authentication, authorization, rate-limit, validation, data-source, and analytical query failures.
- Capture endpoint, status, duration, correlation information, and workflow outcome without recording sensitive results unnecessarily.
- Monitor data freshness separately from API success because a successful response may reflect an older source refresh.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration rather than isolated scripts
Martini provides a maintainable workflow layer around ThoughtSpot APIs, authentication, pagination, transformations, business rules, target-system writes, and operational error handling. This avoids scattering token management and endpoint-specific logic across scripts.
Reusable integration assets
Teams can expose controlled APIs, reuse workflow logic, and standardize mappings for analytics exports, user provisioning, TML promotion, and embedded access orchestration. Martini can also process JSON, CSV, and TML-related payloads through the same integration estate.
Operational control
Scheduling, checkpoints, retries, validation, monitoring, and secure configuration provide a clearer operating model than point-to-point integrations. The design can evolve when ThoughtSpot API versions, content models, permissions, or target systems change.
- Centralize authentication and environment configuration.
- Apply consistent validation and idempotency rules.
- Monitor workflow outcomes and retry only appropriate failures.
Frequently asked questions
ThoughtSpot can be integrated through its REST APIs, analytics and data access APIs, supported TML and metadata interfaces, and deployment-specific data-upload or file methods. Enterprise workflows can retrieve Answers and Liveboards, synchronize users and groups, promote modeled content, and deliver approved analytical results to databases, files, or business applications. Because a universal webhook model is not confirmed, scheduled polling or specifically documented callbacks may be required.
Yes. Martini can integrate with ThoughtSpot by consuming its REST APIs, orchestrating session or bearer-token authentication, processing analytics and data exports, synchronizing users and groups, and handling TML or metadata workflows. Martini can also expose controlled APIs for embedded analytics orchestration and process supported JSON, CSV, or TML-related payloads.
No. A dedicated ThoughtSpot connector is not required. Martini can use ThoughtSpot’s confirmed REST APIs, authentication mechanisms, analytics and data interfaces, supported file exchanges, TML-related APIs, and any specifically confirmed callback mechanisms.
Lonti does not charge an additional per-connector or per-vendor fee to integrate ThoughtSpot. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from ThoughtSpot, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
Use the ThoughtSpot REST APIs as the primary integration method, confirming the supported API generation and endpoint family for the tenant. Use analytics and data access APIs for authorized Answer or Liveboard results, TML and metadata interfaces for governed promotion, and supported file or data-upload methods when appropriate. OAuth should not be assumed for every REST API.
A universal webhook framework for changes to Answers, Liveboards, users, groups, worksheets, and tables was not confirmed. Specific callbacks, scheduled delivery, or surrounding-product notifications may exist, but they must be verified for the deployment. Martini can receive a confirmed callback through an exposed API or use scheduled polling when event coverage is unavailable.
Martini can map ThoughtSpot objects and analytical results into canonical or target-specific models, validate schemas, traverse pagination, and normalize timestamps and numeric formats. Stable identifiers and idempotent upserts help prevent duplicate users, groups, exports, and promoted assets. Workflows should also account for export limits, token expiration, permissions, data freshness, and source-schema changes.
Yes. Martini can expose a controlled API that authenticates and authorizes callers, invokes permitted ThoughtSpot REST operations, applies business rules, and returns a constrained response. This is useful for embedded analytics access, trusted-authentication orchestration, user entitlement checks, or shielding client applications from ThoughtSpot-specific API and credential handling.
Related Martini documentation
API Workflows
Data Processing
Connect ThoughtSpot with Martini
Build governed ThoughtSpot integrations with REST APIs, analytics exports, user and group synchronization, TML promotion, and embedded-access workflows using Martini.