Query and inspect ThreatLocker computers.

Common workflows:

• Find computers by logged-in user: action=list, searchBy=2, searchText="username"

• Find computers by IP: action=list, searchBy=4, searchText="192.168.1.100"

• List computers needing review: action=list, kindOfAction="NeedsReview"

• Get computer details by ID: action=get, computerId="..."

• View check-in history: action=checkins, computerId="..."

• Get installation info for new deployments: action=get_install_info

• Rename / re-group a computer: action=edit, computerId="...", computerGroupId="...", name="..."

• Move a computer to another org: action=move_org, computerId="...", computerGroupId="...", organizationId="...", osType=1, targetComputerGroupId="...", targetOrganizationId="..."

• Remove computers from the Portal: action=delete, deleteComputers=[{computerId, computerName, organizationId}] (same org; does NOT uninstall)

• Restart every agent in the org: action=restart_org (includeChildOrganizations=true also hits child orgs)

• Remove duplicate records: action=remove_duplicate

Pitfalls:

• get returns the editable computer record, not live protection state; read current mode/isolation from list results or maintenance_mode history.

• This is the triage entry point: find a box here, grab its computerId/organizationId/computerGroupId, then hand off to maintenance_mode, approval_requests, or action_log.

Permissions: View Computers, Edit Computers (for modifications), Install Computers (for install info). Pagination: list and checkins actions are paginated (use fetchAllPages=true to auto-fetch all pages). Key response fields: computerId, computerName, computerGroupName, lastCheckin, action (Secure/Installation/Learning/MonitorOnly), threatLockerVersion.

Related tools: computer_groups (manage groups), maintenance_mode (maintenance history), action_log (audit events)

List and inspect ThreatLocker computer groups.

Computer groups organize computers and define policy scope. Policies are applied to groups, not individual computers. The "global" group (includeGlobal=true) permits applications across all groups.

Common workflows:

• Get all groups with computers: action=list, includeAllComputers=true

• Get group dropdown for UI/selection: action=dropdown

• Get groups across organizations (MSP): action=dropdown_with_org, includeAvailableOrganizations=true

• Filter by OS type: osType=1 (Windows), 2 (macOS), 3 (Linux)

• Get groups for approval workflow: action=get_for_permit

• Get group by install key: action=get_by_install_key, installKey="..."

Permissions: Super Admin (for list), Edit Computers, Edit Computer Groups, View Computers. Key response fields: computerGroupId, name, osType, computerCount, organizationId.

Related tools: computers (list computers in groups), policies (policies applied to groups)

Search, inspect, create, update, and delete ThreatLocker applications.

Applications are collections of file rules (hashes, paths, certificates) that define what software is allowed or denied. ThreatLocker comes with built-in applications for common software, and you can create custom ones.

Common workflows:

• Find an application by name: action=search, searchText="Chrome"

• Find apps by file hash: action=search, searchBy=hash, searchText="abc123..."

• Find apps by certificate: action=search, searchBy=cert, searchText="Microsoft"

• Get ThreatLocker research on an app: action=research, applicationId="..."

• List files in an application: action=files, applicationId="..."

• Find apps actively permitted: action=search, permittedApplications=true

• Find recently created custom apps: action=search, category=1, orderBy=date-created

• Find matching apps by file properties: action=match, hash="...", path="...", cert="..."

• Get apps for maintenance mode: action=get_for_maintenance

• Get app for network policy: action=get_for_network_policy, applicationId="..."

• Create custom application: action=create, name="My App", osType=1

• Update application metadata: action=update, applicationId="...", name="...", osType=1

• Manage a child org's app: add managedOrganizationId="child-org-guid" to create/update

• Add file rules to application: action=add_file, applicationId="...", osType=1, fileRules=[{hash:"..."}, {fullPath:"...", cert:"..."}]

• Remove file rules from application: action=remove_file, applicationId="...", applicationFileIds=[7111524894, 7111524907] (get IDs via action=files)

• Delete application (no policies): action=delete, applications=[{applicationId:"...", name:"...", organizationId:"...", osType:1}]

• Force delete (with policies): action=delete_confirm, applications=[...]

Pitfalls:

• Hash-only file rules must contain only the hash (no path/cert); file paths need double-escaped backslashes in JSON.

• create makes metadata only — add file rules in a follow-up add_file call; then build a policy and deploy it.

• remove_file needs applicationFileId values from action=files first.

• Built-in applications take policy precedence over custom apps.

Permissions: Edit Application Control Applications. Pagination: search and files actions are paginated (use fetchAllPages=true to auto-fetch all pages). Key response fields: applicationId, name, osType, computerCount, policyCount. Research fields: concernRating, reviewRating, categories, countriesWhereCodeCompiled.

Related tools: policies (see policies using this app), action_log (see app activity), approval_requests (pending approvals for this app)

Manage ThreatLocker policies.

Use list_all to search policies by computer group / org / filter without an applicationId; use list_by_application when you already have an applicationId.

Policies define what applications can run on which computer groups. A policy links an application (set of file rules) to a computer group with an action (permit/deny/ringfence).

Common workflows:

• Get policy details by ID: action=get, policyId="..."

• List all policies for an application: action=list_by_application, applicationId="...", organizationId="..."

• Find policies for a specific group: action=list_by_application, applicationId="...", organizationId="...", appliesToId="group-id"

• Include deny policies in results: action=list_by_application, ..., includeDenies=true

• Create new policy: action=create, name="...", applicationIds=["..."], computerGroupId="...", osType=1, policyActionId=1

• Update policy (full replace - get first!): action=update, policyId="...", name="...", applicationIds=["..."], computerGroupId="...", osType=1, policyActionId=1

• Delete policies: action=delete, policyIds=["..."], organizationId="..."

• Copy policies between groups: action=copy, osType=1, policyIds=["..."], sourceAppliesToId="...", sourceOrganizationId="...", targetAppliesToIds=["..."]

• Deploy pending changes: action=deploy, organizationId="..."

IMPORTANT: After create/update/delete/copy, deploy changes with action=deploy to push to computers. IMPORTANT: Update is a full replace — use action=get first to read current values, then provide ALL fields.

Policy actions: Permit (allow), Deny (block), Ringfence (allow but restrict network/storage access)

Pitfalls:

• Precedence is first-match-wins (Global > Global Group > Entire Org > Computer > Computer Group). New policies land at the bottom unless orderBefore=true.

• monitorMode=1 (Secured) creates an explicit deny that overrides Learning Mode; monitorMode=2 is Monitor Only.

• allowRequest/killRunningProcesses are only valid with policyActionId=2 (Deny).

• Ringfence requires policyActionId=6 + ringfencingOptions (5 restrict flags + rf* arrays). rfFilePolicy permission: permit 1=read-only/2=read+write, deny 1=deny-write/2=deny-read+write. rfNetworkPolicy.server uses "tag:".

• policySchedules requires policyScheduleStatus=2; networkExclusions pairs with restrictNetworkAccess=true.

• update is FULL-REPLACE: get first, then resend ALL nested arrays (ringfencingOptions/policySchedules/networkExclusions/userGroups/parentProcessIdList/requestEmailAddressesList) you want to keep — omitting one removes it. Payload-verified, NOT live-tested.

• Scoping: userGroups needs allUserGroups=false; deviceType needs allDevices=false; parentProcessIdList needs parentRestrictionEnabled=true (apps must match the policy osType); applicationSelection=1 (all apps) needs a name containing "Permit All" or starting "Default - "; notifyOnRequest/requestEmailAddressesList are Deny-only (policyActionId=2).

Permissions: View Application Control Policies, Edit Application Control Policies. Pagination: list_by_application is paginated (use fetchAllPages=true to auto-fetch all pages). Key response fields: policyId, name, policyActionId, applicationId, computerGroupId, isEnabled.

Related tools: applications (what the policy permits), computer_groups (where policy applies), action_log (see policy enforcement)

Query ThreatLocker unified audit logs.

The action log records all application control events: permits, denies, network access, file operations, PowerShell execution, elevation requests, and more. This is your primary tool for investigating what happened on endpoints.

Common workflows:

• Find all denies in last 24 hours: action=search, startDate="...", endDate="...", actionId=99

• Find denies on a specific computer: action=search, ..., hostname="COMPUTER-NAME"

• Find network blocks: action=search, ..., actionType=network, actionId=2

• Find PowerShell executions: action=search, ..., actionType=powershell

• Get details of a specific event: action=get, actionLogId="..."

• Track a file's history across all computers: action=file_history, fullPath="C:\path\to\file.exe"

• Aggregate by user to find who's triggering denies: action=search, ..., groupBys=[1]

• Get file download details: action=get_file_download, actionLogId="..."

• Get policy conditions for permit: action=get_policy_conditions, actionLogId="..."

• Get testing environment details: action=get_testing_details, actionLogId="..."

Pitfalls:

• onlyTrueDenies/simulateDeny only filter when used alone or together; they force actionId=99 internally. "True" deny = enforced block; "simulated" = would-have-blocked on a Monitor/Learning computer.

• When calling get/get_file_download, pass the sourceTableId matching the row the eActionLogId came from (default 2=DenyActionLog will miss permit/baseline/eventlog events).

• groupBys takes at most 2 fields; prefer it over fetching raw rows for aggregation.

• username/deviceType are NOT supported search filters here (the V2 endpoint ignores them); pivot on hostname/fullPath/policyId or use groupBys=[1] to break down by user.

Permissions: View Unified Audit. Pagination: search action is paginated (use fetchAllPages=true to auto-fetch all pages). Performance: always use date filters — queries without startDate/endDate can be very slow on large organizations. Use groupBys to aggregate instead of fetching all raw rows. Key response fields: actionLogId, fullPath, processPath, hostname, username, actionType, policyName, applicationName.

Related tools: computers (find computer IDs), applications (identify apps), approval_requests (handle denied software)

Query ThreatLocker approval requests.

When users encounter blocked software and request access, it creates an approval request. Admins review these requests to decide whether to permit the software by creating policies.

Common workflows:

• List pending requests: action=list, statusId=1

• Get pending request count: action=count

• Find requests for a specific user: action=list, searchText="username"

• Get request details: action=get, approvalRequestId="..."

• Get file info for download/analysis: action=get_file_download_details, approvalRequestId="..."

• Get permit options (apps, groups): action=get_permit_application, approvalRequestId="..."

• Get storage request details: action=get_storage_approval, approvalRequestId="..."

• Approve a request: action=permit. Two-step — call get_permit_application first, round-trip its opaque "json" blob into permitJson, then pick permitMode + policyLevel. Payload-verified, NOT live-tested: validate in a non-prod org before relying on it.

Request statuses: 1=Pending (needs review), 4=Approved, 6=Not Learned (learning mode), 10=Ignored, 12=Added to Application, 13=Escalated (from Cyber Heroes), 16=Self-Approved

Pitfalls:

• list defaults to newest-first (isAscending=false) — the right default for triaging the pending queue.

• Permitting a request is a two-step flow: call get_permit_application first and round-trip its opaque "json" blob; don't synthesize it.

• Before approving a Built-In matching app, confirm the file isn't a shared DLL matching unrelated apps (you'd permit the whole built-in).

Permissions: View Approvals, Approve for Entire Organization/Group/Single Computer. Pagination: list action is paginated (use fetchAllPages=true to auto-fetch all pages). Key response fields: approvalRequestId, username, fullPath, actionType, statusId, computerName, requestDateTime.

Related tools: action_log (see the deny event), applications (find matching apps), policies (create permits)

Query ThreatLocker organizations.

Organizations are the top-level containers in ThreatLocker. MSPs have a parent organization with child organizations for each client. Enterprises may have organizations per business unit or location.

Common workflows:

• List child organizations: action=list_children

• Search for a client org: action=list_children, searchText="client name"

• List all nested children (full tree): action=list_children, includeAllChildren=true

• Get installation auth key: action=get_auth_key

• Get orgs available for moving computers: action=get_for_move_computers

• Provision a client org: action=timezones (pick an id) → action=create_child, displayName="...", timezoneId="..." → get_auth_key → deploy

• Rotate the org auth key: action=rotate_auth_key (DESTRUCTIVE — invalidates the old key and breaks existing deploy scripts)

The organizationId is needed for many API calls (policies, applications, etc.) to scope the request to a specific organization.

Pitfalls:

• get_auth_key returns the install/auth key used to deploy agents and to resolve groups via computer_groups get_by_install_key.

Permissions: View Organizations, Edit Organizations, Super Admin - Child. Pagination: list_children is paginated (use fetchAllPages=true to auto-fetch all pages). Key response fields: organizationId, name, displayName, dateAdded, computerCount.

Related tools: computers (computers in org), computer_groups (groups in org), policies (policies in org)

Query and run ThreatLocker reports.

Access pre-built and custom reports configured in the ThreatLocker portal. Reports provide aggregated views of security data across your organization.

Common workflows:

• List all available reports: action=list

• Run a specific report: action=get_data, reportId="..." (get IDs from list action first)

• Review security posture: list reports, then run relevant compliance or audit reports

• Export data for external analysis: run a report and process the returned data

Permissions: View Reports. Key response fields: reportId, name, description, reportData (dynamic columns per report type).

Related tools: action_log (raw audit events), system_audit (portal audit trail), computers (device inventory)

Query ThreatLocker maintenance mode history for computers.

Maintenance mode temporarily changes a computer's protection level. Types include:

• Monitor Only (1): Logs but doesn't block (audit mode)

• Installation Mode (2): Allows new software installs, auto-learns new applications

• Learning Mode (3): Monitors and records software usage without blocking

• Tamper Protection Disabled (6): Allows ThreatLocker service changes

Common workflows:

• View maintenance history for a computer: action=get_history, computerId="..."

• Audit who put computers in installation mode: check history across computers

Maintenance mode history shows who enabled it, when, duration, and what applications were learned during that time.

Pitfalls:

• Learning Mode (3) requires a "Default - (Group Name)" Default Deny policy to exist in the group, or it silently does nothing.

• Isolation (14) and Lockdown (15) require ThreatLocker Detect and Agent >= 8.2.

• usersList entries are "DOMAIN\USERNAME" and only apply when allUsers=false; default window is 1 hour if no end time is given.

Permissions: Edit Computers, Manage Application Control Installation Mode, Manage Application Control Learning Mode. Pagination: get_history is paginated (use fetchAllPages=true to auto-fetch all pages). Key response fields: maintenanceModeId, maintenanceTypeId, displayName, startDateTime, endDateTime, addedBy, endedBy.

Related tools: computers (get computer IDs, see current mode), computer_groups (group-level modes)

Query ThreatLocker scheduled agent actions.

Scheduled actions are pending operations on ThreatLocker agents, primarily version updates. Updates are batched and scheduled within maintenance windows to avoid disruption.

Common workflows:

• List all scheduled actions: action=list

• Search with filters: action=search, organizationIds=["..."], computerGroupIds=["..."]

• Get scheduled action details: action=get, scheduledActionId="..."

• Get available targets for scheduling: action=get_applies_to

Scheduled action types: Version Update (scheduledType=1).

Pitfalls:

• isAscending is inverted by the API: true (or omitted) sorts descending (high to low); set false for ascending.

• search (GetByParameters) is keyed by scheduledId — pass it to filter to a specific scheduled action's computers; use list for the top-level set.

Permissions: Edit Computers, Edit Computer Groups, View Computers. Pagination: search action is paginated (use fetchAllPages=true to auto-fetch all pages). Key response fields: scheduledAgentActionId, scheduledType, scheduledDateTime, computerName, computerGroupName, status.

Related tools: computers (see current versions), computer_groups (target groups for updates), organizations (filter by org)

Query ThreatLocker portal audit logs.

System audit tracks administrator actions in the ThreatLocker portal: logins, policy changes, approvals, configuration modifications. This is different from action_log which tracks endpoint events.

Common workflows:

• Find all logins in date range: action=search, startDate="...", endDate="...", auditAction=Logon

• Find failed login attempts: action=search, ..., auditAction=Logon, effectiveAction=Denied

• Find changes by a specific admin: action=search, ..., username="admin@company.com"

• Find policy modifications: action=search, ..., auditAction=Modify, details="policy"

• Get health center dashboard: action=health_center, days=7

• Search health center by location: action=health_center, searchText="lat:X&long:Y"

Audit actions: Create (new objects), Delete (removals), Logon (portal access), Modify (changes), Read (views). Supports * wildcard in text fields.

Permissions: View System Audit, View Health Center. Pagination: search and health_center actions are paginated (use fetchAllPages=true to auto-fetch all pages). Key response fields: systemAuditId, username, action, effectiveAction, details, ipAddress, dateTime.

Related tools: action_log (endpoint events, not portal events), organizations (filter by org)

Query ThreatLocker tags for network and policy management.

Tags are reusable labels for IP addresses, domains, ports, or other network identifiers. They simplify policy management by letting you reference "CRM Servers" instead of listing individual IPs.

Common workflows:

• List all available tags: action=dropdown

• Include ThreatLocker built-in tags: action=dropdown, includeBuiltIns=true

• Get tag details by ID: action=get, tagId="..."

• Update tag membership: action=update, tagId="...", organizationId="..." (full-object replace — get first, resend ALL item arrays you want to keep; there is no insert/delete endpoint)

Tags are used in:

• Network Control policies (allow/deny traffic to tagged destinations)

• Ringfencing (restrict app network access to tagged resources)

• Storage Control (restrict file access to tagged paths)

Parent organization tags appear as "parentOrgName\tagName" format.

Pitfalls:

• Use dropdown to get the label+value (tagId) needed when building network/ringfence policy payloads.

• Parent-organization tags use the "ParentOrg\TagName" format.

Permissions: Edit Network Control Policies, Manage Tags, Edit Application Control Policies. Key response fields: tagId, name, tagType, values (IP/domain/port entries).

Related tools: policies (use tags in policy rules), applications (ringfence with tags)

Query ThreatLocker storage control policies.

Storage policies define rules for file and folder access on endpoints — controlling which applications can read, write, or execute from specific storage locations (local drives, USB devices, network shares).

Common workflows:

• List all storage policies: action=list

• Search by name: action=list, searchText="USB"

• Filter by computer group: action=list, appliesToId="group-id"

• Get policy details by ID: action=get, storagePolicyId="..."

Pitfalls:

• Read-only tool: storage policy creation/editing is not available via the public API (no documented write endpoint).

• Storage policies are first-match top-down — permits must be ordered above denies.

Permissions: View Storage Control Policies, Edit Storage Control Policies. Pagination: list action is paginated (use fetchAllPages=true to auto-fetch all pages). Key response fields: storagePolicyId, name, policyType, osType, computerGroupName, isEnabled.

Related tools: policies (application control policies), computer_groups (where policy applies), applications (what the policy permits)

Query ThreatLocker network access control policies.

Network access policies define firewall rules for endpoints — controlling which applications can make or receive network connections, and to which destinations (IPs, ports, domains).

Common workflows:

• List all network access policies: action=list

• Search by name: action=list, searchText="RPC"

• Filter by computer group: action=list, appliesToId="group-id"

• Get policy details by ID: action=get, networkAccessPolicyId="..."

Pitfalls:

• Network Control has no Global policy level (unlike application control).

• Tag-based rules need the tag label + id resolved via the tags tool (dropdown); parent-org tags use the "ParentOrg\TagName" format.

• direction: 1=Inbound, 2=Outbound; policyActionId: 1=Permit, 2=Deny.

Permissions: Edit Network Control Policies, View Network Control Policies. Pagination: list action is paginated (use fetchAllPages=true to auto-fetch all pages). Key response fields: networkAccessPolicyId, name, computerGroupName, isEnabled, applicationName.

Related tools: policies (application control policies), computer_groups (where policy applies), tags (network tags used in policies)

Query available ThreatLocker agent versions.

Returns all agent versions available in the portal, including which are enabled for installation, which is the default for new groups, and when each was released.

Common workflows:

• List all available versions: action=list

• Find the latest version: action=list, look for highest version number with isEnabled=true

• Check if a specific version is still available: action=list, search results for version string

• Identify the default version for new computer groups: action=list, look for isDefault=true

• Plan upgrade rollouts: action=list, compare to installed versions from computers tool

Permissions: Edit Computers, Edit Computer Groups, View Computers, Install Computers. No pagination — returns all versions in a single response. Key response fields: label (version string), value (version ID), isEnabled, dateTime (release date), isDefault, OSTypes.

Related tools: computers (see installed versions per machine), scheduled_actions (schedule version updates), computer_groups (group-level version settings)

Query ThreatLocker online devices.

Returns devices currently connected and reporting to the ThreatLocker platform. Useful for real-time visibility into which endpoints are active.

Common workflows:

• Check how many devices are online right now: action=list

• Verify a specific computer is connected: action=list, then search results for hostname

• Monitor fleet connectivity after a network change: action=list, compare count to computers tool total

• Paginate through large device lists: action=list, pageNumber=2, pageSize=100

Permissions: View Computers. Pagination: list action is paginated (use fetchAllPages=true to auto-fetch all pages). Key response fields: computerName, computerGroupName, lastCheckin, ipAddress.

Related tools: computers (full inventory with details, modes, groups), computer_groups (group membership and structure)

Manage saved Unified Audit / investigation searches.

A saved search has two parts: searchData (the reproducible parameters, as JSON) and saveParameters (a human-readable label). saveSearchPageId selects which page the search belongs to (valid values 1-10; e.g. the Unified Audit page).

Common workflows:

• List saved searches for a page: action=list, saveSearchPageId=

• Save a search: action_log build_search_string (→ saveParameters label) → action=insert, saveSearchId=, saveSearchPageId=, organizationId="...", searchName="...", saveParameters="Any Deny", searchData={the search params object}

• Delete a saved search: action=delete, saveSearchId="..."

Pitfalls:

• searchData is REQUIRED and must be valid JSON (object or JSON string) — the API deserializes it and returns an opaque 500 if it is missing or malformed. (Verified live 2026-07-06.)

• saveParameters is the display label from action_log build_search_string (e.g. "Any Deny").

• saveSearchPageId must be a valid page type (1-10); 0/other values return "Page type wasn't found".

• insert requires you to supply a fresh saveSearchId GUID.

Permissions: View Unified Audit.

Related tools: action_log (build_search_string produces saveParameters)

Request and retrieve forensic file uploads from endpoints.

Common workflows:

• Request a file upload: action=insert, uploadRequestId=, organizationId="...", computerId="...", shA256="..." (or filepath)

• Retrieve an upload request: action=get, uploadRequestId="..."

Pitfalls:

• The SHA-256 field is literally "shA256" (odd casing) in the API.

• insert requires you to supply a fresh uploadRequestId GUID.

• Writes are payload-verified, NOT live-tested.

Permissions: View Unified Audit / forensics.

Related tools: action_log (locate the file event), computers (get computerId)