Liongard API

An agent with this tool turns Liongard’s Actionable Alerts into PSA tickets, one per alert, and answers a ticket from the client’s Liongard data: what the alert found, what changed on the client’s systems, and whether the alert cleared after the fix.

​

What It Does

• Find the client’s environments from the Organization Mapping
• Read Actionable Alerts: number, title, finding and action, priority, status, client, and the inspection that raised them
• Raise a ticket in your PSA for each new alert, once per alert, with the finding and the action (a ServiceNow incident or request, or a ticket in your other PSA)
• Read change detections: what changed, on which system, and when
• Read a system’s latest inspection data, its timeline, metric values and the client dashboard’s numbers
• Run an inspection again, and manage launchpoints, agents, asset inventory, environments, metrics, users and webhooks

The agent calls Liongard through the Vendor API tool, with liongard as the vendor id. Sandbox scripts can call Liongard too, under the same permissions.

​

Permission Groups

Liongard’s lists and queries that take a body are sent as POST, but Neo treats them as reads. Running an inspection is sent as a GET, but Neo treats it as a change: it follows the group’s approval setting, and a read-only agent or script cannot send it.

​

Access Profiles

​

Changes that always ask a technician

These always wait on a technician, whatever the settings: deleting an environment, and any write whose body sets a value on a field whose name holds password, passwd, passphrase, secret, token, privatekey, apikey, sharedkey, credential or secureconfig, or is key, psk, pwd or pin, unless another word in the name says it describes the secret (PasswordNeverExpires, TokenLifetime).

​

Ticket runs stay on the client’s environments

On a run for a ticket, Neo sends only calls about an environment mapped to the ticket’s company: a path that names the environment (v1/environments/<id>), or a call on the client’s alerts, detections, systems, timeline, launchpoints, agents or inventory that carries the environment in Neo’s environment_id parameter. Neo then keeps only that environment’s rows of a list, returns a record only when it belongs to that environment, and sends a change to a record only after reading that the record belongs to it. Calls that reach every client (the environment list, counts, users, metrics, webhooks and every bulk call) run only without a ticket, for example in a scheduled agent or a chat.

​

Not available through Neo

Neo refuses these before it calls Liongard:

• Signing in with a user’s name and password, and its MFA step, because the response is a session token
• Creating an access key, because the response is a working key and secret, and deleting one, because the list is the calling user’s own keys and one of them is the key Neo calls with
• Generating the webhook signing key, because the response is a secret and a new key breaks the check your webhook receivers make
• Evaluating an expression over an inspection, and creating or changing a metric, because the expression picks values out of raw inspection data, where a password can arrive with no field name beside it. Read the system’s latest data instead, and write metrics in Liongard

Neo also replaces the value of every such field (by the same name rule) in each Liongard response before an agent or a script sees it, inside a launchpoint’s configuration text too. A change that sends that placeholder back is refused, and so is a filter or sort that names such a field.

​

Setup

See Connecting Liongard to Neo.