Server Integration Methods
When building an integrated solution with Tanium, one of the first decisions you need to make is how information will flow between Tanium and your system. Choosing the right method from among the several options available requires evaluating your use case requirements, architecture, and the Tanium modules involved.
Integration Methods Summary Table
This summary chart provides a quick summary to help you identify which method is the best for your needs. If you have any questions about the different integration methods or capabilities or need advice selecting the best option for your project, head over to the Forum where the community and Tanium Partner team are ready to help.
| Requirement | Connect Module | GraphQL API | Platform REST API | Asset API | Threat Response API | Other Module APIs |
|---|---|---|---|---|---|---|
| Push data to cloud service | ||||||
| Pull online endpoint data into remote system | ||||||
| Pull all endpoint data into remote system | ||||||
| Perform module-specific actions, such as comply scan | ||||||
| Perform action on endpoint(s) | ||||||
| Push endpoint data into Tanium | ||||||
| Gather evidence | ||||||
| Zero Trust: endpoint risk check | ||||||
| Intel Management | ||||||
| Get software utilization info |
Preferred Option For Specific Use Cases
Method 1: Connect Module
The Tanium Connect module can be configured to deliver data to downstream systems based on a schedule or triggered by events. It is a flexible solution that can use a variety of delivery mechanisms and data formats. The Connect module is generally the easiest and most straightforward method of integration. The Connect Module Guide will help you get started.
Best for
The Connect Module is the best integration method for use cases where you need a regular delivery of a specific type of data from Tanium to a file, syslog, webhook, or other common destination type. Delivery can also be event-triggered, such as with Threat Response alerts.
Not Suited for
The Connect Module is for scheduled outgoing data feeding an external system. It is not the best solution for externally triggered or ad hoc data requests. When integrating with TaaS (Tanium as a Service), Connect destinations are limited to Cloud services and cannot be configured to deliver to on-prem destinations.
Method 2: GraphQL API Gateway
The Tanium API Gateway is a GraphQL interface for querying data from Tanium. It is the newest integration method, and going forward,it is the preferred option for integrating with Tanium over the various REST APIs. The API Gateway Guide provides helpful details. If there are gaps or capabilities you would like to leverage that are not yet available through the Gateway, please let us know about them in the Suggestions Forum. Developer feedback is critical in planning out our API roadmap.
Best for
The API Gateway is best for querying data about online and offline systems. It is the solution of choice for scheduling software deployments, direct endpoint connections, and more.
Not Suited for
The API Gateway is new and does not yet cover all the capablities seen in the Platform or Module REST APIs. It may not be able to fully support integration with specific modules, certain types of targeting and filtering, or use cases involving Group management.
Method 3: Platform REST API
The Tanium Core Platform REST API can be used to gather information about managed endpoints, deploy actions to them, evaluate the health of the Tanium deployment, and much more. Many of the core functions that can be performed in the Tanium Interact module or administration screens can be done via the REST API. This integration method has the most capabilities of the available options.
Best for
The Platform REST API is the best choice when you need to pull data from Tanium based on an external trigger (manual user request, automated workflow, etc) and that data is not available from the sensors configured for collection from TDS. Much of the commonly requested data such as IP, Mac Address, or Operating System is collected by TDS and therefore should be queried using the API Gateway.
The Platform REST API is also the right choice if you need to deploy actions or make administrative changes, such as creating or modifying computer or action groups.
Not Suited for
The Platform REST API should be used when the capability you need has not yet been made available through the newer API Gateway. It is also not suited for performing unadvised or unsupported activities against the Tanium platform. Just because you CAN do something with REST API does not mean that you SHOULD. Tanium will not approve an integration that uses the REST API to do unscalable or dangerous activities (like pushing unapproved sensor code to endpoints for example). It is best to ask questions on the Developer Forum about what you are planning to do first if you are unsure.
Method 4: Module REST APIs
Some modules in Tanium have their own REST API with unique capabilities. If you need to pull data from the sensors included with these modules, then you can simply query the data with API Gateway or create a saved question in Connect. If you need to perform module-specific actions, such as quarantining an endpoint with Threat Response or pulling Asset report data for example, then you may need to leverage that module's REST API.
Best for
The various module REST APIs are best reserved for those cases that cannot be accomplished through any of the other methods available. The Asset API is a useful source for SIU data and endpoints that have aged out of TDS. The Asset API can also be used to push externally sourced endpoint inventory and metadata into Tanium. The Threat Response API is useful for many Threat Hunting or Security scenarios. It is advised that you run your implementation plan by us before building out your solution if you plan to make use of a module API so that we can help you determine if that is the best option available.
Not Suited for
This method is generally not recommended when another method can meet your needs.