Choose the Right Connection Method
Compare Radiant Security ingestion methods (Agent, API connector, webhook, Syslog, AWS S3) and pick the right one for each data source.
Compare Radiant's five ingestion methods and select the right fit for each data source in your stack.
Radiant supports multiple methods for connecting your security tools and log sources. Each method targets a different environment and a different set of trade-offs. Choosing correctly during onboarding ensures every data source reaches the Radiant AI engine reliably, with the depth and coverage required for accurate alert triage.
Ingestion methods at a glance
Radiant supports five primary ingestion methods. The table below summarizes when each one applies; detailed guidance follows in the next section.
On-premises sources with no public-facing API
A Docker container deployed in your environment collects logs locally and forwards them to Radiant.
API connector
Cloud-hosted tools that expose a vendor API
Radiant pulls alerts, events, and metadata directly from the vendor API on demand.
Webhook
Sources that support outbound HTTP event push
The source pushes events to a Radiant webhook endpoint as they occur.
Syslog
On-premises devices that support outbound log streaming
The device streams logs to Radiant over TLS on port 6514.
High-volume log pipelines already consolidated in S3
Radiant reads from a customer-owned S3 bucket, triggered by SNS notifications.
Method details
The Radiant Security Agent is a lightweight Docker container deployed in your environment, either on-premises or in a private cloud. It collects logs from local services and forwards them to Radiant.
Best for: On-premises network devices and servers that are not internet-facing and cannot send data directly to a cloud service. Examples include Cisco, Fortinet, and Palo Alto firewalls.
Why use it: The Radiant Security Agent is the right choice when a source cannot expose data over a vendor API, either because no API exists or because the available API is too limited to support reliable triage.
Trade-offs: The Radiant Security Agent requires installation and configuration in your environment, which adds setup overhead compared to an API connector. Use the Radiant Security Agent when it is the only path to the data. If a vendor API exists, use that first.
For setup instructions, see Install the Radiant Security Agent.
Radiant Security Agent vs. Syslog. If your on-premises device supports Syslog, the Radiant Security Agent is still the preferred approach. The Radiant Security Agent provides a managed, reliable forwarding mechanism with stronger operational guarantees. Syslog remains available when the Radiant Security Agent is not suitable for your environment.
Use an API connector for any tool that exposes a vendor API. Radiant uses purpose-built connectors to pull alerts, events, and metadata directly from your security tools.
Best for: Cloud-hosted tools with a vendor API. Common examples include Microsoft, CrowdStrike Falcon, Okta, and SentinelOne.
Why use it: Vendor APIs are built for programmatic access and include mechanisms for scaling, throttling, and error handling. The connection is more reliable and feature-rich than a log stream, and Radiant can request exactly the data it needs, when it needs it, without over-ingesting.
Trade-offs: Some vendor APIs impose rate limits or caps on query frequency. If your tool has restrictive API limits, ingesting the source data into Radiant Log Management may be a better fit. Radiant can then query its own copy of the data without external constraints. Your Radiant team can help you evaluate this during onboarding.
Webhooks let your tools push events to Radiant as they occur, rather than waiting to be polled.
Best for: Sources that support outbound HTTP event notifications but do not expose a queryable API. Common examples include Check Point Avanan, Elastic SIEM, Salt Security, and Vicarius. Webhooks also support custom internal solutions and custom correlation rules through Radiant's Custom Webhook Events and Custom Webhook Alerts connectors, which accept logs from any source that meets the required field and format prerequisites.
Why use it: Webhooks are quick to set up and deliver events with low latency. They are a good fit when an API connector is not available and the source can reliably push the data Radiant needs.
Trade-offs: Webhooks are less reliable and less feature-rich than API connectors. There is no built-in error handling, retry logic, or request-level context. You receive the raw event stream and nothing more. For sources where data completeness matters, prefer an API connector or the Radiant Security Agent.
Syslog is a push-based forwarding option for on-premises devices that support outbound log streaming.
Best for: On-premises network devices or security tools that support Syslog where you need a lightweight setup without deploying the Radiant Security Agent.
Why use it: Syslog is faster to configure than the Radiant Security Agent and works well for sources where you do not need the full reliability and feature set of an API connector or managed forwarder.
Trade-offs: Syslog has no built-in error handling, retry logic, or request-level context. For data sources where completeness matters, the Radiant Security Agent is the stronger choice.
Syslog connections to Radiant require TLS on port 6514 for secure transport over the internet.
With Bring Your Own Bucket (BYOB), Radiant ingests data directly from an S3 bucket you own and manage. When new logs land in the bucket, an SNS notification triggers Radiant to process the data, typically within minutes.
Best for: High-volume log pipelines, compliance-driven retention requirements, and environments where you consolidate data in S3 before forwarding to Radiant. BYOB also fits sources that lack a real-time API but can export to S3.
Why use it: BYOB lets you retain full ownership and long-term storage of raw logs outside of Radiant while still feeding Radiant the data it needs for triage.
Trade-offs: BYOB reads from your bucket at a controlled pace and does not impact your storage performance. Setup is lightweight and requires no infrastructure on your end beyond the S3 bucket itself.
For setup instructions, see Bring Your Own Bucket (BYOB).
Decision guide
Work through these questions in order. Stop at the first match and use that ingestion method.
Does the source expose a vendor API?
Use an API connector. This is the default for cloud-hosted tools and the most feature-rich option, with built-in handling for scaling, throttling, and error recovery.
Is the source on-premises with no internet-facing API?
Use the Radiant Security Agent. The Agent is the most reliable way to collect and forward data from environments that cannot expose a vendor API.
Does the source push events over HTTP?
Use a webhook when an API connector is not available. Webhooks are quick to set up and deliver events with low latency, but offer fewer reliability guarantees than an API connector.
Is the source on-premises and Syslog-capable, but the Radiant Security Agent is not viable?
Use Syslog as a fallback. Syslog is faster to configure than the Radiant Security Agent but lacks the same operational guarantees.
Are you ingesting high-volume logs already consolidated in S3, or do you need to retain ownership of the raw log archive?
Use AWS S3 with a customer-managed bucket (BYOB). BYOB is purpose-built for high-volume pipelines and lets you keep full ownership of your raw log archive.
Ingest into Log Management or query on demand
Not every source needs to be fully ingested into Radiant Log Management. For some sources, Radiant can query data on demand rather than indexing and storing all of it. This reduces ingestion volume and avoids retaining data you may not need in Radiant.
The trade-off is that on-demand querying leaves your data in two places: the original SIEM or external platform, and Radiant. If you want a single search surface across all of your security data, ingesting into Log Management gives you that unified view.
External platforms also impose their own limits on API calls and data lake queries. Ingesting into Log Management removes that dependency. Radiant controls its own query layer without being subject to third-party rate limits.
Your Radiant team can help you decide what makes sense for each source during onboarding.
Last updated
Was this helpful?