.png)
Tanium Integration Guide
Integrate Tanium endpoint, compliance, vulnerability, and action data with enterprise systems through REST APIs, Tanium Connect deliveries, and Martini workflows.
Tanium integration options at a glance
Tanium's principal integration mechanism is its REST API, which can expose Computers, Computer Groups, Questions, Sensors, Packages, Actions, and module-specific resources according to the deployment and installed products. Tanium Connect provides selected outbound data delivery to configured destinations, including supported HTTP destinations, but it is not a universal webhook service for every Tanium object. Questions and Actions support population-oriented, batch-style operations, with pagination, polling, or result-window handling depending on the API. Martini can authenticate securely, schedule Tanium queries, receive supported Tanium Connect deliveries, normalize results, and route them to enterprise applications or databases.
| Integration point | Supported by Tanium? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Tanium REST APIs are the principal programmatic mechanism for reading Computers, Computer Groups, Questions, Sensors, Packages, Actions, and module-specific resources. Available paths and operations depend on the platform version, deployment model, and installed modules. | Martini can consume Tanium REST APIs from workflows, map responses, apply business rules, and expose normalized results through Martini APIs. API definitions and environment-specific credentials can be managed as reusable integration assets. |
| Webhooks / outbound callbacks | Limited | Tanium Connect can deliver selected Tanium data to configured external destinations, including supported HTTP destinations. Coverage, schedules, filters, payloads, and delivery behavior depend on the Tanium product and Connect configuration. | Martini can expose an HTTP endpoint or receive webhook-style deliveries, validate the source payload, transform it, and route it to downstream systems. The workflow should verify that the required Tanium source and event are actually available through Tanium Connect. |
| Bulk / async / batch APIs | Limited | Questions can target endpoint populations and return batch-style inventory, compliance, or operational results. Actions can also target Computer Groups, while pagination, asynchronous execution, polling, and result-window behavior vary by API and question type. | Martini can schedule bounded batch workflows, process pages or result windows, persist checkpoints, poll asynchronous operations where required, and reconcile partial results. Workflows can apply backoff to avoid excessive Tanium workload. |
| Authentication | Yes | Tanium API access uses deployment- and version-dependent credentials, tokens, or sessions. Tanium roles and permissions determine access to modules, Computers, Questions, Sensors, Packages, Actions, and Computer Groups. | Martini can keep Tanium credentials in environment-managed secrets, configure authenticated HTTP requests, and separate credentials by environment. Workflows can distinguish authentication failures from authorization failures for safer operations. |
| File / attachment APIs | Not confirmed | Tanium Packages may contain software, scripts, or deployment materials, but the research does not confirm a general-purpose attachment API for ordinary business-object integration. | Martini should use the documented Tanium REST resources or supported Tanium Connect destinations instead of assuming a general attachment interface. File handling can be added only when a specific Tanium product or endpoint documents it. |
| Database / analytics access | No | Direct database access to the Tanium platform is not the recommended integration model. Tanium data should generally be obtained through REST APIs, Tanium Connect, or supported product exports. | Martini can write transformed Tanium data to a supported downstream database after consuming an API or outbound feed. It should not connect directly to the Tanium platform database as an integration method. |
How Tanium exposes data and business events
Tanium REST APIs
Tanium REST APIs provide the main integration surface for platform and module operations. Depending on deployment, version, and installed products, integrations can retrieve Computers, Computer Groups, Questions, Sensors, Packages, Actions, and module-specific resources.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to the applicable Tanium endpoint, calls the documented resource, validates the response, maps Tanium fields into a canonical model, and routes the result to an application, database, or Martini API. Resource availability and permissions are verified during implementation rather than assumed globally.
Implementation sequence
Tanium Connect outbound delivery
Tanium Connect can deliver selected Tanium data to configured external destinations, including supported HTTP destinations. It provides a product- and configuration-dependent outbound pattern rather than universal webhooks for every Tanium object or event.
Martini implementation pattern
Martini implementation pattern: expose a controlled Martini HTTP endpoint for the supported Tanium Connect delivery, validate the request and payload, transform the selected Tanium data, and route it to downstream systems. The integration must confirm the Tanium Connect source, schedule or trigger, destination behavior, and delivery format.
Implementation sequence
Tanium batch Questions and Actions
Questions can query endpoint populations, and Actions can execute Packages against selected Computers or Computer Groups. These population-oriented operations are suitable for scheduled inventory, compliance, and controlled remediation workflows.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a bounded workflow, submits or retrieves the documented Question or Action operation, processes pages or result windows, and persists a checkpoint or Action ID. For remediation, the workflow validates approval and target scope before execution and polls status when necessary.
Implementation sequence
Common Tanium integration patterns
Pattern 1: Sync Tanium endpoint inventory to ServiceNow
When to use this pattern
Use this pattern when ServiceNow or another operational system needs a current view of Tanium-managed endpoints. A scheduled synchronization is generally more predictable than assuming universal event delivery, especially when the required Tanium data is obtained through Questions.
Integration direction
Example Mapping
| Tanium Field | Canonical Field | Target Field |
|---|---|---|
| Computer ID | endpoint.externalId | Configuration item external key |
| Hostname | endpoint.hostname | Configuration item name |
| Operating System | endpoint.operatingSystem | Operating system |
| IP Address | endpoint.ipAddress | IP address |
Martini implementation pattern
A scheduler starts a Martini workflow that retrieves Computers or Question results in bounded pages. Martini validates required endpoint identifiers, maps and enriches the data, applies retirement and duplicate rules, and upserts ServiceNow configuration items. Checkpoints and reconciliation identify missing or no-longer-reporting endpoints, while transient failures are retried with backoff and malformed records are isolated.
Martini capabilities used
- workflows
- scheduler triggers
- API consumption
- data mapping
- business rules
- error handling
Pattern 2: Send Tanium vulnerability or compliance findings to a security platform
When to use this pattern
Use this pattern to normalize Tanium Comply, vulnerability, risk, or compliance results for Microsoft Sentinel, Splunk, or a governance platform. It is appropriate when the target needs stable findings, severity, policy, and remediation state rather than raw Tanium responses.
Integration direction
Example Mapping
| Tanium Field | Canonical Field | Target Field |
|---|---|---|
| Computer ID | finding.assetId | Device identifier |
| Severity | finding.severity | Alert severity |
| Policy or Control ID | finding.controlId | Rule or control identifier |
| Remediation State | finding.status | Finding status |
Martini implementation pattern
Martini retrieves the relevant Tanium module data through documented REST resources or receives a supported Tanium Connect delivery. The workflow validates module-specific fields, normalizes severity and status values, retains Tanium finding and Computer identifiers, and writes the target event or finding. Idempotency keys prevent duplicate findings, and permission, rate-limit, and partial-result failures are handled separately.
Martini capabilities used
- API consumption
- webhook reception
- data mapping
- normalization
- business rules
- retry handling
Pattern 3: Create and monitor approved Tanium remediation Actions
When to use this pattern
Use this pattern when a ServiceNow approval, Jira workflow, or security process may initiate a Tanium Package or Action. Because Actions can affect endpoint populations, this pattern requires explicit authorization, target validation, correlation, and status monitoring.
Integration direction
Example Mapping
| Tanium Field | Canonical Field | Target Field |
|---|---|---|
| Approved request ID | remediation.correlationId | Action correlation reference |
| Computer Group | remediation.targetScope | Action target group |
| Package ID | remediation.packageId | Action package |
| Action status | remediation.executionStatus | Request or task status |
Martini implementation pattern
Martini receives or retrieves an approved request, validates the requester, package, Computer Group, and duplicate state, and then calls the applicable Tanium Action API only if the deployment exposes that operation and the service account is authorized. It stores the Action ID, polls status where needed, updates the originating system, and routes failed or ambiguous executions for review rather than blindly retrying.
Martini capabilities used
- API orchestration
- authorization rules
- data mapping
- workflow state
- polling
- error handling
Pattern 4: Process Tanium Connect data through a Martini API
When to use this pattern
Use this pattern when Tanium Connect supports the required source and can deliver selected data to an HTTP destination. It is useful for supported outbound feeds where receiving data promptly is preferable to broad scheduled Questions.
Integration direction
Example Mapping
| Tanium Field | Canonical Field | Target Field |
|---|---|---|
| Tanium object identifier | event.sourceId | Event source identifier |
| Computer name | event.endpointName | Host |
| Finding or action state | event.status | Event status |
| Delivery timestamp | event.observedAt | Event time |
Martini implementation pattern
Martini exposes a controlled API endpoint, validates the Tanium Connect delivery, and rejects malformed or unauthorized payloads before processing. The workflow transforms the selected data into the target schema, applies filtering and enrichment, forwards it to Splunk or another destination, and records a delivery reference. Duplicate detection and bounded retries protect against repeated delivery or transient target failures.
Martini capabilities used
- API exposure
- webhook reception
- data mapping
- validation
- routing
- monitoring
Applications commonly integrated with Tanium
Tanium data is commonly incorporated into security operations, IT service management, analytics, endpoint-management, and collaboration processes. Martini can mediate these flows so Tanium identifiers, permissions, approvals, and synchronization state remain consistent across systems.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| ServiceNow | Synchronize endpoint inventory, vulnerability findings, compliance issues, incidents, remediation tasks, and approved action requests. | Tanium → Martini → ServiceNow | A scheduled Martini workflow retrieves Tanium Computers or module-specific findings, maps them to ServiceNow assets, incidents, tasks, or changes, and preserves Tanium identifiers as correlation keys. A separate inbound workflow can validate approved ServiceNow requests before invoking an applicable Tanium Action and polling its status. |
| Splunk | Centralize Tanium endpoint, security, compliance, and operational data for search, correlation, and security analytics. | Tanium → Martini → Splunk | Martini consumes Tanium REST responses or supported Tanium Connect deliveries, normalizes endpoint and finding fields, applies filtering and enrichment, and forwards structured events to Splunk through its available ingestion endpoint. Bounded retries and source identifiers help prevent duplicate events. |
| Microsoft Sentinel | Feed Tanium endpoint risk, vulnerability, compliance, and response information into Microsoft security operations workflows. | Tanium → Martini → Microsoft Sentinel | A Martini workflow retrieves or receives supported Tanium data, converts it into the target security-event model, adds stable Tanium and environment identifiers, and submits it to the configured Microsoft Sentinel ingestion interface. The workflow records delivery status and isolates malformed or unauthorized records. |
| Microsoft Teams | Notify operations and security teams about selected Tanium findings, action failures, or compliance changes. | Tanium → Martini → Microsoft Teams | Martini filters Tanium findings or action-status results against notification rules, formats a concise message, and sends it to the configured Teams endpoint through an approved HTTP integration. Deduplication and severity thresholds prevent repeated notifications for unchanged findings. |
| Jira | Create engineering or operations work items for endpoint remediation, software deployment, vulnerability, or compliance work. | Tanium → Martini → Jira | Martini maps Tanium findings or endpoint issues to Jira projects, issue types, priorities, and assignees, using the Tanium identifier as an external correlation key. Later status changes can be evaluated by business rules before an approved Tanium Action is initiated. |
| Microsoft Intune | Correlate Tanium endpoint intelligence with Microsoft device-management data and coordinate remediation ownership. | Tanium → Martini → Microsoft Intune | Martini retrieves Tanium Computers and relevant Intune device data through their supported APIs, normalizes endpoint identifiers and ownership attributes, and applies reconciliation rules. Conflicts are routed for review rather than automatically triggering endpoint actions. |
| CrowdStrike Falcon | Correlate Tanium inventory, security findings, and response activity with endpoint detection and response data. | Tanium → Martini → CrowdStrike Falcon | Martini orchestrates calls to the relevant Tanium and CrowdStrike APIs, matches endpoints using governed identifiers, and publishes a normalized security view or response workflow. Permission checks, rate-aware retries, and source-specific error handling are applied independently to each platform. |
| Microsoft Entra ID | Associate Tanium endpoint and remediation context with identity, access, and user-oriented security processes. | Microsoft Entra ID → Martini → Tanium | Martini retrieves approved identity or group context from Entra ID, combines it with Tanium Computer or Computer Group data, and applies authorization rules before exposing or initiating Tanium operations. Sensitive identity and endpoint fields are minimized in logs and downstream payloads. |
How to build a Tanium integration in Martini
Objective
Establish the Tanium endpoint, deployment-specific authentication method, service account, and permissions required by the integration.
Instructions in Martini
- Identify the Tanium Cloud or on-premises API endpoint and applicable platform version
- Create or select a least-privilege Tanium service account with access to required modules and resources
- Store tokens, credentials, and endpoint configuration in Martini secrets and environment configuration
- Confirm HTTPS access and distinguish authentication failures from permission failures
Objective
Select a scheduled REST workflow or supported Tanium Connect delivery based on the required data freshness and event coverage.
Instructions in Martini
- Use a scheduler for inventory, compliance, and action-status synchronization where event delivery is unavailable
- Use a Martini HTTP endpoint when Tanium Connect supports the required source and destination
- Set an appropriate cadence that accounts for Question scope, Sensor cost, and Tanium capacity
- Define the checkpoint, correlation, or delivery identifier used by the workflow
Objective
Call the documented Tanium resource or receive the configured outbound payload while accounting for result size and asynchronous behavior.
Instructions in Martini
- Call the relevant REST API resource, Question, or module-specific endpoint
- Handle pagination, continuation, polling, result windows, or expiration behavior documented for the selected API
- Validate response structure, identifiers, timestamps, and module-specific fields
- Bound concurrency and apply backoff for rate limits and transient platform errors
Objective
Coordinate Tanium calls, validation, enrichment, target calls, and state management in a maintainable Martini workflow.
Instructions in Martini
- Separate read-only synchronization from action-triggering workflows
- Add validation and authorization gates before creating or executing Tanium Actions
- Persist Tanium Computer, Question, Action, finding, and correlation identifiers
- Route partial results and non-retryable errors to an operational review path
Objective
Convert Tanium-specific response structures into canonical and target-system models without assuming identical module schemas.
Instructions in Martini
- Map Computers, Questions, Actions, findings, and module-specific fields to canonical fields
- Normalize severity, status, timestamps, operating-system values, and identifiers
- Preserve source identifiers as external keys for idempotent writes
- Use validation rules for missing columns, changed sensor output, and unexpected data types
Objective
Enforce scope, approval, duplicate, and reconciliation rules before writing data or affecting endpoints.
Instructions in Martini
- Validate Computer Group and endpoint scope for remediation operations
- Use stable Tanium identifiers and source environment values for duplicate prevention
- Apply severity, ownership, retirement, and notification thresholds
- Require explicit approval and correlation for workflows that initiate Actions
Common Tanium data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Computers | Represent managed endpoints and attributes such as hostname, operating system, IP address, platform, and health information. | ServiceNow, Splunk, Microsoft Intune, CrowdStrike Falcon, Microsoft Sentinel | Martini retrieves Computer data directly or through Questions, maps stable endpoint identifiers to the target model, and uses upsert and reconciliation logic to avoid duplicate or stale assets. |
| Sensors | Define data collection methods used to retrieve endpoint information. | ServiceNow, Splunk, internal data stores, security platforms | Martini invokes documented Question or Sensor-related API operations and treats sensor output types as version- and module-dependent. Transformations should validate columns and data types before downstream writes. |
| Questions | Query endpoint populations using Sensors and selected Computer Groups for inventory, compliance, or operational data. | ServiceNow, Splunk, Microsoft Sentinel, databases | Martini schedules Questions, handles pagination or asynchronous result retrieval where required, normalizes result columns, and stores checkpoints or stable identifiers for incremental synchronization. |
| Packages | Define software, scripts, or command content that can be deployed to endpoints. | ServiceNow change workflows, audit stores, security operations platforms | Martini can read documented Package information and use it in approval and audit workflows. Package execution should not be assumed without a permitted Action operation and explicit authorization. |
| Actions | Represent executions of Packages against selected Computers or Computer Groups. | ServiceNow, Jira, Splunk, operational databases | Martini can initiate an Action only where the applicable API and permissions are available, then persist an Action ID, poll status, correlate results, and apply duplicate and approval controls. |
| Computer Groups | Define static or dynamic endpoint populations used to target Questions, Actions, and management policies. | ServiceNow, governance platforms, security operations systems | Martini retrieves group membership or metadata through documented APIs, validates target scope before action workflows, and records the group context alongside synchronized findings or execution requests. |
Authentication and security considerations
Deployment-specific authentication
Tanium API authentication depends on the deployment model, platform version, and selected API. API tokens or session-based credentials may be used, and OAuth 2.0 should not be assumed for every Tanium endpoint.
Least-privilege access
Use a dedicated Tanium service account with only the module, Computer Group, Question, Sensor, Package, and Action permissions required by the workflows. Action-triggering integrations require stronger controls than read-only synchronization.
Secrets and transport
- Store Tanium credentials, tokens, and Martini endpoint credentials in environment-managed Martini secrets.
- Use HTTPS for API communication and rotate credentials according to organizational policy.
- Do not expose tokens, passwords, package content, command arguments, or sensitive endpoint data in logs.
Operational considerations for Tanium integrations
Throughput and result size
Questions can query large endpoint populations and may require pagination, polling, asynchronous handling, or result-window management. Bound batches and avoid unnecessarily frequent broad queries.
Rate limits and workload
Account for Tanium capacity, Sensor cost, concurrent Questions, endpoint impact, and HTTP 429 or transient 5xx responses. Use bounded retries with backoff.
Idempotency and reconciliation
Persist stable Computer, finding, Question, Action, or module-specific identifiers as external keys. Define how retired, deleted, or no-longer-reporting Computers are detected and reconciled.
Schema variation
Response models vary by Tanium version, deployment, installed modules, Sensor output, and Question result columns. Validate schemas and avoid hard-coding undocumented status values or fields.
Action safety
Before creating an Action, validate authorization, package identity, target Computer Group, approval state, and duplicate status. Store the Action ID and poll execution status where required.
Testing and monitoring
Test with representative endpoint populations and module-specific responses. Monitor workflow logs, partial results, authentication failures, permission errors, malformed responses, and downstream delivery status.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than one API call
Scripts often combine authentication, pagination, transformation, retries, and target writes in one implementation. Martini separates these concerns into reusable workflows and APIs that can be maintained as Tanium resources and downstream systems evolve.
Support both scheduled and outbound flows
Martini can schedule Tanium REST API workflows for predictable inventory or compliance synchronization and can receive supported Tanium Connect deliveries through controlled HTTP endpoints.
Apply governed business rules
Mappings, validation, approval checks, duplicate prevention, and target routing can be implemented consistently before data is written or a potentially impactful Tanium Action is initiated.
Improve operational resilience
Centralized error handling, bounded retries, checkpoints, correlation identifiers, and monitoring provide clearer recovery paths than unmanaged point-to-point scripts.
Frequently asked questions
Tanium can be integrated primarily through its REST APIs, which expose platform and module resources such as Computers, Questions, Computer Groups, Packages, and Actions. Tanium Connect can also deliver selected data to configured external destinations, including supported HTTP destinations. Scheduled workflows are appropriate for inventory, compliance, and action-status synchronization when event delivery is not available.
Yes. Martini can integrate with Tanium by consuming its REST APIs, receiving supported Tanium Connect HTTP deliveries, scheduling synchronization workflows, mapping Tanium data, and exposing normalized APIs to downstream systems. The available resources and operations depend on the Tanium deployment, version, installed modules, and service-account permissions.
No. A dedicated Tanium connector is not required. Martini can use Tanium's confirmed native integration mechanisms, including REST APIs, supported Tanium Connect outbound deliveries, Tanium authentication methods, and scheduled workflows.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Tanium with Martini. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Tanium, cloud infrastructure, or other third-party systems depending on subscriptions, usage, and deployment model.
Tanium REST APIs should be treated as the primary method for current integrations. Tanium Connect is useful for selected outbound data delivery where the required source, schedule or trigger, payload, and HTTP destination are supported. GraphQL was not confirmed and SOAP was not supported in the supplied research, so neither should be assumed.
Tanium Connect can deliver selected Tanium data to configured external destinations, including supported HTTP destinations. This is a product- and configuration-dependent outbound pattern, not a universal webhook for every Tanium object or event. The required source, delivery behavior, and payload must be confirmed for each integration.
Use scheduled Questions or documented REST resources when a predictable batch process is required, and use Tanium Connect when the required outbound delivery is available. Martini can process bounded result sets, retain checkpoints, and preserve stable Tanium Computer, finding, Question, or Action identifiers as external keys so repeated runs update existing target data instead of creating duplicates.
Yes. Martini can expose a controlled REST API that retrieves, normalizes, and presents selected Tanium data to downstream applications. The façade can centralize authentication, authorization, field mapping, validation, rate-aware orchestration, and consistent error handling without exposing Tanium-specific endpoints directly.
Related Martini documentation
API Integration
Workflows
Connect Tanium to your enterprise systems
Use Martini to build governed Tanium integrations for endpoint inventory, compliance, security operations, and approved remediation workflows.