SonicWall Capture Integration via API

Purpose

This guide explains how to obtain the credentials required in the SonicWall Capture Client Management console and how to use them in Logsign USO to ingest Capture Client endpoint-protection alerts via the REST API.

This integration is distinct from the SonicWall integrations already documented for Logsign. "Sonicwall Response Integration" and "Adding Sonicwall Firewall via Syslog" cover the classic SonicOS network firewall (syslog-based traffic/threat logs and response actions). This guide instead covers SonicWall Capture Client Management (also marketed as Capture Security Center), SonicWall's separate, cloud-hosted endpoint protection management console. Capture Client exposes its alert data through a REST API rather than syslog, so a poller-based (pull) integration is used here instead of a syslog source.

Prerequisites

You need administrative access to your SonicWall Capture Client Management console (https://captureclient-XX.sonicwall.com, where XX is your tenant's regional assignment) in order to create a dedicated user account for Logsign.

The account used by Logsign authenticates directly against the Capture Client Management API with an email and password; it does not go through the MySonicWall OAuth flow. Create a separate account for this integration rather than reusing a personal administrator login, so access can be revoked independently later.

Step 1: Identify Your Capture Client Console URL

Sign in to your Capture Client Management console. The address in your browser bar, for example https://captureclient-36.sonicwall.com, is your tenant's regional console URL; the numeric suffix (-36, -01, etc.) identifies the region your tenant was provisioned in. European tenants may see a -XXeu suffix instead (for example captureclient-36eu.sonicwall.com). Copy this address; it is the Host value you will enter in Logsign in Step 3.

Step 2: Create a Dedicated User Account for Logsign

1. In the Capture Client Management console, create a new user account intended solely for API access (do not reuse your own MySonicWall login).
2. Give this account a strong, unique password and record the account's email address.
3. Confirm the account can sign in to the console with these credentials before configuring Logsign.

Logsign uses this email and password to call the console's own /api/login endpoint directly. This is a separate, supported authentication path from the MySonicWall API Key flow that SonicWall documents for issuing longer-lived (7-day) Capture Client API tokens; Logsign does not use that alternate flow.

Step 3: Configure the Integration in Logsign USO

After identifying your console URL and creating the dedicated account, log in to Logsign USO and add a new "Sonicwall Capture Management" API data source. You will be asked for:

Logsign exchanges these credentials for a Bearer access token automatically on each poll cycle by calling POST /api/login, then queries GET /api/alerts for new records using the timestamp of the last processed alert as the time filter. You do not need to generate or manage a token yourself.

Notes and Limits

• This poller retrieves endpoint-protection alert data from the Capture Client Management /api/alerts endpoint only. It does not cover classic SonicOS firewall traffic/threat syslog data or SonicWall's response/action integration; those remain separate, already-documented integrations.
• If polling stops and the source logs repeated authentication errors, verify first that the dedicated account's password has not been changed or the account has not been disabled in the Capture Client console. Update the credentials in the Logsign data source afterward.
• The current implementation calls the alerts endpoint once per poll cycle without iterating additional result pages. If your tenant generates a very large number of alerts within a single polling interval, confirm with SonicWall support whether the alerts endpoint paginates results beyond a default page size, as this has not been independently confirmed against SonicWall's official API reference in this review.
• Rate-limit handling (HTTP 429) is not implemented as a distinct retry/backoff path in the current poller; a rate-limited response is treated the same as any other request failure and is retried only on the next scheduled poll.
• Field-level normalization mapping for alert data is not yet populated in the shipped poller; alerts are currently classified under a generic Security/Other/Info event mapping until a dedicated mapping is defined from live alert samples.