> For the complete documentation index, see [llms.txt](https://docs.vectra.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.vectra.ai/configuration/tuning/creating-triage-filters-via-api.md). # Creating triage filters via API Create and manage triage filters through the Vectra API, with examples for QUX API v2.5. Triage filters can be viewed, created, and modified through the public API. In this article, we will explore an example of creating a new triage filter using the v2.5 (QUX) API. Please see the following resources for details on using Vectra's APIs: Respond UX * [Vectra Platform API Guide v3.4](/configuration/access/api-rux/v34-api-guide-rux.md) Quadrant UX * [REST API Quick Start Guide for Postman v2.5 using OAuth2 (QUX)](/configuration/access/api-qux/v25-postman-quick-start-guide-using-oauth2.md) * [REST API Guide v2.5](/configuration/access/api-qux/v25-api-guide-qux.md) * [Vectra v2.5 Public Postman Collection](https://www.postman.com/vectra-internal/workspace/vectra-ai/collection/7429442-509c593b-8de4-4aa3-ac05-e07934eb9f17) In the following example, we will create a triage filter that applies to a specific host, which we will reference by it’s ID. In this case the ID is 3345. The ID can be obtained from the API (https\://\/api/v2.5/hosts) or by looking at the full URL for a host and noting the ID ad the end of the URL (https\://\/hosts/3345.) Triage filters can be applied to hosts, IPs/subnets, or all hosts. Only one of these options should be provided. Hence, if the intent is to triage on hosts, then it will not be possible to triage based on IP/subnet in the same triage filter. Examples of each:\ "host": \[3345, 3350] #applying to hosts with IDs 3345 and 3350\ "ip": \["192.168.1.1"]\ "all\_hosts": true In this example, we are going to create a triage filter that reclassifies a "Brute-Force Attack" in the "LATERAL MOVEMENT" category, of type "ssh", that is targeting the 10.1.1.0/24 and 10.1.2.0/24 subnets. When creating a triage filter, the detection\_category and detection name must be provided exactly as documented in the [Understanding Vectra AI Detections](/operations/analyst-guidance/understanding-vectra-ai-detections.md) article. Following is an example of using the curl utility to create a triage filter. The string supplied for triage\_category is the new category type that the detection will be reclassified as. Specifying the filter is a whitelist ("is\_whitelist": true) will preclude the need to set the triage\_category, as this tells Vectra to create a whitelist filter vs a more common triage filter. ``` curl -X POST \ https:///api/v2.5/rules/ \ -H 'Authorization: Token ' \ -H 'Content-Type: application/json' \ -d '{ "detection_category": "LATERAL MOVEMENT", "triage_category": "SSH.Brute.Force-SystemAuth", "detection": "Brute-Force", "remote1_ip": ["10.1.1.0/24", "10.1.2.0/24"], "remote1_proto": ["ssh"], "is_whitelist": 0, "description": "Normal Authentication Activity", "host": [3345] }' ``` Using curl to view the new entry after it was created: ``` curl -H "Authorization: Token " -k https:///api/v2.5/rules/ { "id": 167, "url": "https:///api/v2.5/rules/167", "description": "Normal Authentication Activity", "created_timestamp": "2018-01-05T19:37:48Z", "last_timestamp": null, "host": [ "https:///api/v2.5/hosts/3345" ], "all_hosts": false, "is_whitelist": false, "sensor_luid": null, "ip": null, "priority": 2, "remote1_ip": [ "10.1.1.0/24", "10.1.2.0/24" ], "remote1_proto": [ "ssh" ], "detection_category": "LATERAL MOVEMENT", "triage_category": "SSH.Brute.Force-SystemAuth", "detection": "Brute-Force" } ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.vectra.ai/configuration/tuning/creating-triage-filters-via-api.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.