Sending Cato Data to External Platforms with the Custom HTTP Push Integration

Overview

Use the Custom HTTP Push integration to stream Cato events, and optionally flows, directly to any external platform that accepts JSON or newline-delimited JSON (NDJSON) over HTTP. This integration is designed for organizations that want to send Cato data to systems that don't have a dedicated Cato integration.

Data is pushed continuously as it's generated, rather than retrieved on a scheduled basis, allowing downstream systems to receive near real-time updates without polling.

Common use cases include:

• SIEM and SOC platforms: Centralize Cato events for correlation, alerting, investigation, and long-term retention alongside other security data.

• Custom log collection and analytics: Send events to log collectors, data lakes, analytics pipelines, or operational platforms that accept HTTP-based JSON payloads, such as DDI/IPAM platforms, custom observability solutions, or internal processing services.

Native Integrations vs. Custom HTTP Push

Cato provides purpose-built integrations for several commonly used platforms, including Splunk, Microsoft Sentinel, CrowdStrike, and Azure Storage. When a native integration is available for your destination, it is generally the recommended option because it is optimized for that platform and may provide platform-specific capabilities.

Use the Custom HTTP Push integration when your destination does not have a dedicated Cato integration, or when you need to deliver Cato events to a custom application or service that accepts JSON or NDJSON over HTTP.

Prerequisites

Before configuring Custom HTTP Push, verify that the destination platform supports all of the following:

• HTTP POST or PUT requests
• JSON or newline-delimited JSON (NDJSON)
• The standard Cato payload without requiring a custom request body, vendor-specific wrapper, or additional directive

The payload structure is fixed. Fields cannot be added, removed, or rearranged.

Destination Compatibility

A platform is typically compatible if it can ingest plain JSON objects or an NDJSON event stream exactly as Cato sends them. Examples include SentinelOne, Securonix, and Trend AI.

A platform is not compatible if its ingestion API requires a proprietary payload structure, such as an envelope, wrapper, or control line that must be added to the request body. Examples include Elastic and Datadog.

Set up a Custom HTTP Push Integration

Step 1: Gather Parameters

From your target platform, obtain:

• Ingestion URL: the HTTP(S) endpoint that accepts events

• Authentication details: the integration supports Custom Header(s), API Key, Bearer Token, or Basic Auth. If your vendor expects a prefixed value (e.g. Bearer <token>), you'll enter the entire string — prefix included — as a single value. It's stored encrypted on the Cato side.

Step 2: Test With curl

Validate the destination independently using a command-line curl request. This isolates vendor-side issues (auth, endpoint, payload acceptance) and gives you a working request you can reuse directly in the connector setup.

Example that doesn't succeed: Elastic

curl -X POST "https://<your-elastic-endpoint>/_bulk" \
-H "Authorization: ApiKey <KEY>" \
-H "Content-Type: application/x-ndjson" \
--data-binary $'{"create":{"_index":"logs-cato.events-default"}}\n{"message":"test event from curl","event_type":"test","timestamp":"2026-07-05T12:00:00Z"}\n'

This fails the connector's requirements, even though the curl call itself may succeed against Elastic. The payload requires a create directive line before every event line; the integration has no way to inject that extra line, since the body format is fixed.

Example that succeeds: SentinelOne

curl -i "https://ingest.us1.sentinelone.net/services/collector/raw?sourcetype=cato_events" \
-H "Authorization: <token>" \
-H "Content-Type: application/x-ndjson" \
--data-binary $'{"event_type":"test"}\n'

This works because SentinelOne's HEC raw endpoint accepts a plain event object per line — no wrapper, no extra directive — which is exactly what the connector sends. When a curl test like this succeeds, you can use it verbatim in the connector setup:

• URL: paste the full endpoint including query parameters (for example, ?sourcetype=cato_events)

• Auth: Custom Headers → header name Authorization, value set to your real token (stored as Secret)

• Body: set the content type to match what you tested (application/x-ndjson here)

If your curl test succeeds, continue to step 3.

Step 3: Configure the Connector

1. In the CMA, go to Resources > Integrations > Configured Integrations, and click New.

2. Under Integration, select Custom HTTP Integration.

3. Under Capability, choose Data Export.

4. Under Auth, select the method that matches what you validated with curl (Custom Headers, API Key, Bearer Token, or Basic Auth).

5. Enter a Name and optional Description.

6. Enter the URL — the same endpoint you tested with curl.

7. Add your Custom Headers (or equivalent auth fields) — carry over the exact header names and values from your successful curl command. Each value can be stored as Secret or Plain.

8. Under Body, confirm the content type (application/json by default; NDJSON also supported).

The request body sent by the connector is not configurable: you cannot add custom fields or restructure the payload. This is the same limitation referenced in the Prerequisites, and it's why Elastic and Datadog aren't supported, since both require content in the body beyond a plain event object.

9. Under Data Sources, select Events, Flows, or both.

10. Optionally scope what's sent using the Events Filter and Flows Filter (match ANY of the configured filter groups).

11. Choose whether to track errors with connector events. This is recommended so that delivery failures surface as Cato events you can alert on.

12. Save the configuration and confirm the status shows Connected.

Troubleshooting

• Curl succeeds, but Cato shows Connectivity Error: Double-check that headers/auth entered in Cato exactly match what you used in curl, including any required prefix (for example, Bearer) as part of the encrypted value.

• No events are arriving at my external platform: Check your Events Filter/Flows Filter. An overly narrow filter can silently exclude everything.

• Vendor rejects payload: Review the prerequisites. Your vendor likely requires a custom body structure that this connector can't produce.