Ticketing

The findings.createTicket tool creates one remediation ticket from a selection of findings. It runs the same server-side path as ticket creation from a findings page in the Brinqa Platform UI: it consolidates the selected findings onto a new ticket record, starts the SLA timers, applies the assignment, and records the run in the application event log. This capability is available in two ways:

• BrinqaIQ Assistant (chat UI): describe the findings and the ticket in natural language. The Assistant collects the required inputs in the conversation and confirms before it creates the ticket.
• MCP integration: the findings.createTicket tool lets any MCP-compatible client create a ticket from agent prompts. See MCP Integration for setup.

Every call executes with the permissions of the user account bound to your API token, so the selection is scoped to findings that user can read, and creation is subject to the same ticket-creation permission enforced in the UI. The same operation is also available as a public REST endpoint, POST /v1/api/tickets, for non-agent integrations.

How it works

You supply a finding selection and the ticket attributes; the tool returns a reference to the created ticket. You never pass a ticket model: the ticket type is derived from the finding model (findings of a Vulnerability model produce a vulnerability ticket), so you always work with the findings.

Select the findings with exactly one of the following:

• query: a BQL query whose primary entity is one concrete finding model (for example, critical Vulnerability records on a given host).
• dataModel + datasetIds: the concrete finding model plus an explicit list of finding record ids (up to 1000).

The finding model must be a concrete type such as Vulnerability, not an abstract parent such as Finding: a single ticket type cannot be derived from an abstract parent. The selection must match at least one readable finding.

The following attributes complete the request:

Attribute	Required	Description
slaPolicy	Yes	The SLA definition that sets the remediation timers, identified by exactly one of its numeric record id (preferred) or its uid. The uid field also accepts the definition's display name, which the tool resolves for you.
assigned	No	The user the ticket is assigned to, identified by exactly one of the user's numeric record id or a name. A name is the username, email address, or display name, and the tool resolves it to a record id.
delegates, remediationCampaign, sprint	No	Record references, each given as a record id.

Every record id (the finding datasetIds, the SLA definition, and each reference) is passed as a quoted numeric string. Brinqa record ids exceed JavaScript's safe integer range, so an unquoted JSON number can silently lose precision; the tools require the id as a string and copy it verbatim.

On success the tool returns the new ticket's record id, its derived ticket dataModel, the findingCount attached, and the transactionId of the run.

Because a ticket has side effects that are not reversible by a delete alone (SLA timers start, an owner is notified, the event log records the run), the tool is annotated as destructive: an annotation-aware client such as Claude Desktop, and the BrinqaIQ Assistant, present a confirmation prompt that summarizes the ticket before it is created. A client that does not implement confirmations creates the ticket directly; the server-side ticket-creation permission still applies.

Create a ticket from findings

The Assistant collects the ticket name, summary, SLA definition, and any owner before it calls findings.createTicket, then reports the created ticket's id, its derived model, and the attached findingCount. You can name the SLA definition and the assignee directly, because the tool resolves both for you. The remaining references need a record id; see Set the SLA, owner, and other references.

Example agent prompts:

Create a ticket for the critical Vulnerability findings on host web-01, using the standard remediation SLA.

Open a remediation ticket for Vulnerability findings 2060003840245702686 and 2060003840245702672.

When you identify the findings by record id, name their finding model (for example, "Vulnerability findings") so the tool selects the correct model and derives the correct ticket type.

Set the SLA, owner, and other references

slaPolicy is required. If you do not know which SLA definition to use, ask the Assistant to list them; it queries the available SLADefinition records so you can select one by name. You can also send the definition's display name in uid and let the tool resolve it.

assigned is the one reference you can name instead of looking up. Send the user's username, email address, or display name in name, and the tool resolves it to a record id. The resolution happens inside the tool, so it works on the MCP integration as well as in the Assistant. If the name matches more than one user, or no user your account can read, the call fails and tells you what to send instead.

delegates, remediationCampaign, and sprint take a record id only. Neither the tool nor the Assistant resolves a name for these, so you cannot refer to them by name in chat: the Assistant renders a BQL result as a table for you but does not read the row values itself, so it cannot pick an id out of one. Ask it to list the records you want, then copy the id from the table into your next message. An MCP client receives the full rows, so an agent on the MCP integration can resolve these references with a BQL query on its own.

Example agent prompt:

Create a ticket named "Q3 critical remediation" for these findings, assign it to Jordan Lee, and apply the 30-day SLA.

The Assistant confirms the assembled ticket (name, the finding selection, the SLA, and the assignee) before it creates it.

Assign a ticket to the calling user

Send the literal value __currentUser__ in assigned.name to assign the ticket to the signed-in user. This is what makes "assign it to me" work: the tool reads the calling credential's own profile, then matches it against the user records your account can read.

warning

__currentUser__ resolves to the owner of the credential that makes the call, which is not necessarily the person prompting the agent. In the Assistant the two are the same. On the MCP integration the caller is your API token, and a token always belongs to the user who generated it, so "assign it to me" assigns the ticket to that user. An agent running unattended, or on behalf of a team, therefore assigns to the token's owner rather than to the person the work is for. Nothing surfaces that first: a confirmation prompt on the MCP integration shows the arguments you sent, and the sentinel is only resolved to a user afterwards, inside the tool. The Assistant does name the resolved user on its confirmation card. When the assignee is not the token's owner, send the username, email address, or display name instead.

When some findings are already ticketed

A finding can belong to only one remediation at a time. If any selected finding already belongs to another ticket, the call fails with a conflict and the response lists the conflicting finding record ids. The Assistant reports which findings are already ticketed and asks whether to create the ticket for the remaining findings (the selection minus the conflicting ids) or to cancel; it does not drop findings silently. If every selected finding is already ticketed, there is nothing left to attach and the Assistant reports that instead of retrying.