Use Cases

ThreatQ provides a comprehensive REST API documentation and an extensive Swagger collection, making it easy to explore available endpoints and parameters. However, we’ve heard that developers and analysts could benefit from use-case–based documentation — examples that walk through common workflows and best practices for interacting with the API.This type of documentation could help: Understand best practices for using the API effectively Avoid inefficient or unsupported methods for common operations Get started faster with real-world, task-based examples We’d like your input on what would be most helpful: What API use cases do you find yourself repeating or struggling to document?

When searching in Spotter AI, entering a generic field name like “hostname” may not return results from all related attributes. Currently, Spotter AI appears to select one matching field (e.g., hostname) instead of searching across all similar variations such as: devicehostname sourcehostname destinationhostname host This means a query like:“Provide me all violations involving the hostname XYZ.acme.com”may return only a subset of results instead of all logs where that hostname appears in any related field. We’d like to better understand how you’d want Spotter AI to interpret these kinds of queries: Should Spotter AI automatically include all fields with a common root term (e.g., “hostname”) in a

Currently, the ThreatQ platform can parse Snort, Suricata, and YARA signatures, extracting metadata and indicators of compromise (IOCs) for use in investigations and automation workflows.At this time, Sigma Rules are not supported for parsing.We know Sigma is a widely adopted detection format across many environments. If Sigma parsing would help improve your threat detection workflows, we’d like to hear your perspective: How do you currently manage Sigma Rules in your threat intelligence processes? What would you expect from a Sigma Rule parser in ThreatQ — e.g., extracted fields, metadata, or IOC types? How might this integration benefit your day-to-day investigations or automation? Your feedback will help shape potential ideas for future development.👉

Current StateCurrently, the ThreatQ user interface does not allow users to create new Indicator Types.While users can create ad-hoc types for other objects such as Events or Attachments, defining new Indicator Types currently requires the ThreatQ API. Some users have leveraged this API to create types such as:    •    Routing Number    •    Bitcoin Address    •    Account Number    •    Phone NumberAlternatively, it’s possible to achieve similar outcomes with Custom Objects, though those typically require more configuration and are not as seamlessly integrated across the platform.We’d like to better understand what would be most useful to you:    •    How important is it for your team to create new Indicator Types through the UI?    •    What kinds of custom indicators do you need to track most often?    •    How would you expect to manage these custom types (na

Current State Currently, when creating a new object in ThreatQ using the Create Object modal, users can set a limited set of fields: Value Type Status Source (and, for some object types, a description) The APIs already allow additional details — such as Tags and Attributes — to be added when creating objects. However, these options aren’t currently available in the UI, which means users often have to go back and edit the object later to add context. We’d like to hear how expanding the Create Object modal could improve your workflows: What extra fields or context would be most helpful to capture at creation time? Would being able to add Tags,

Currently, ThreatQ does not display UI notifications or alerts when a newer version of an installed integration is available in the Marketplace. Users need to manually check for updates and then download and upload the new integration files to update their environment.We’re exploring how to make this experience more seamless and would love your input: How would you like to be notified that an integration is out of date — a badge, alert, or status message? Would you prefer to see version information (installed vs. latest) directly on the Integrations page? How useful would a one-click “Update” option be for your workflows? Would automated or scheduled updates fit into your organization’s change control process? Your feedback will help us understand what kind of update visibil

When a feed fails—or while developing a new feed—users often download Feed Run files to troubleshoot and understand what went wrong.Currently, these files are automatically zipped and password protected. This design helps prevent the files from being flagged by security tools, since they may contain data that appears malicious.However, some organizations (such as financial institutions) have strict security policies that prohibit downloading password-protected files, since they can’t be inspected by endpoint protection tools. This can make troubleshooting feeds more difficult.We’d like to better understand how you’d prefer to handle this scenario: Would you want the option to toggle password protection for Feed Run files directly from the UI? Would it be more useful to view the file contents securely in-platform,