Syxsense Response Integration via API

Purpose

This guide explains how to connect Syxsense to Logsign as a Response (Action) integration and use it from within an Incident or Alarm to pull vulnerability and patch data for a specific device. Syxsense is a cloud-hosted unified endpoint management and vulnerability/patch management platform. This is a separate integration from the Syxsense API poller that ingests Syxsense audit log and vulnerability records into Logsign on a schedule; that poller is documented in "Syxsense Integration via API". This guide covers only the on-demand Response integration configured under Settings > Integrations > Responses.

Unlike the poller, this integration does not run on a schedule. It is invoked on demand, typically from a playbook or a manual action attached to an Incident or Alarm, to look up the current vulnerability and patch status of one device by name and return the results for review or further automation.

Prerequisites

You need a Syxsense API Access Token. Generating a token requires an account with the full administrator role in the Syxsense console; standard analyst accounts cannot open the API Keys screen. This is consistent with Syxsense's own published API documentation, which states that once a user has been granted the full administrator role, the account becomes eligible for API access.

Use least privilege where possible. When you create the token, Syxsense asks you to select a Console Access level for that specific token, separate from the administrator role needed to create it in the first place. Since this Logsign integration only calls the Patches/Vulnerabilities endpoint, scope the token's Console Access level to the narrowest role that can read Patch and Vulnerability Management data for your devices, rather than granting it every module the console offers. The exact set of scoped role names available in your Syxsense tenant's Roles and Scopes screen was not independently verified during this research, so check that screen directly and pick the closest read-focused role.

Logsign version 6.4.7 or later is required; the Syxsense response integration was added in that release.

Step 1: Create API credentials in Syxsense

1. Sign in to your Syxsense console with a full administrator account.
2. Click the Settings (gear) icon in the lower-right corner.
3. Select API Keys.
4. Click New Token.
5. In the New API Token window, enter a Name for the token (for example, "Logsign Response Integration"), optionally set an Expiration Date, optionally lock the token to a specific IP Address, and select the Console Access level as described under Prerequisites above.
6. Click Save.
7. Copy the generated token immediately and store it somewhere safe. Syxsense will not display it again once the window is closed; if it is lost, a new token must be generated.

Format warning. Syxsense's own API documentation shows the token being sent as an Authorization: Bearer <token> header. Based on a direct read of the Logsign Response integration's source code, the Auth Token value you enter in Step 2 is sent to Syxsense exactly as typed, with no Bearer prefix added by Logsign. This is different from the Syxsense API poller, whose code adds the Bearer prefix automatically. To avoid a silent 401, enter the full string Bearer <your token> in the Auth Token field below, not just the raw token by itself. This has not been confirmed against a live Syxsense tenant, since no test credentials were available during this research, but it follows directly from reading the integration's code and from Syxsense's documented header format; if a raw token without the prefix turns out to work in your environment, treat that as the more permissive behavior and either format is safe to try first.

Step 2: Configure the integration in Logsign

In Logsign, go to Settings > Integrations > Responses, search for Syxsense, click Configure, and then +Device to add a new configuration. You will be asked for:

There is no field to enter a base URL. The Syxsense API host (https://api.syxsense.io) is fixed in the integration's code and is not requested from the customer; Syxsense serves this REST API from a single shared host regardless of which console tenant subdomain you normally log in to. This is the same fixed host used by the Syxsense API poller.

Once saved, use the Test button to confirm the token is valid. The test calls Syxsense's GET /api/UserManagement/GetScopes endpoint, which returns the permission scopes associated with your token; this is a genuine live call against Syxsense, not a local format check, so a successful test is a reasonable sign the token and header format are both correct.

Available Methods

Get Vulnerabilities (get_vulnerabilities)

Looks up a single device by name and returns every detected patch/vulnerability record Syxsense has recorded for it, combining per-device status fields with the underlying patch's severity and CVE metadata. Internally this calls GET /api/Patches/VulnerabilitiesByDevice with the device name and a page size of 500, and follows Syxsense's returned pagination links until all pages have been retrieved, so a device with more than 500 findings is still returned in full within a single method call.

The response includes a success flag and a data array. Each entry in that array carries both device-level fields (deviceID, deviceName, userName, locationName, ipAddress, statusPerDevice, firstDetected, firstScanned, detectedDate, reason) and patch-level fields (patchId, patchName, description, securityFamily, cvssSeverity, vendorSeverity, vendor, publishDate, fixable, isPublicAware, isCounterMeasure, isWeaponized, supercededState, solutionPageURL, moreInfoUrl, componentCves). Note that the patch-level severity and CVE metadata fields are present in the actual response based on the integration's code, even though Logsign's own method schema for this integration only documents the device-level fields; if you build a playbook or report against this method's output, do not assume the schema shown in the Logsign UI is the complete field list.

Example use case: an alarm reports repeated exploit attempts against a specific host. Run Get Vulnerabilities on that device to see its full outstanding patch/vulnerability list, including CVSS and vendor severity, before deciding whether to trigger a patch or isolation workflow elsewhere.

Notes and Limits

• This integration exposes a single method, get_vulnerabilities. It does not include device isolation, network quarantine, or patch-scan trigger actions; if you need those capabilities, confirm with Logsign support whether Syxsense's underlying API supports them and whether a future integration update is planned, since the current code does not call any such endpoints.
• This is a static API Access Token, not an OAuth2 flow. There is no token refresh step. The token remains valid until it expires (if an expiration date was set), is revoked, or is regenerated in the Syxsense console.
• The integration does not retry a failed or rate-limited call automatically. If a request fails, the error text from Syxsense's response is passed through to Logsign as-is.
• Syxsense's exact request-per-minute or per-day rate limit for API tokens is not published with a specific number in its publicly available documentation and was not independently verified during this research.
• This is a Response (Action) integration for on-demand lookups during Incident/Alarm handling. It does not collect or ingest Syxsense data as a log source on a schedule; the separate Syxsense API poller covers scheduled ingestion of audit log and vulnerability records.

Troubleshooting