Integrations
Sync cadence, rate limits, and retries
The behind-the-scenes behavior of integrations: how often they sync, how they stay within source-system rate limits, and what happens when a source is unavailable.
Default sync cadences
Every integration has a default sync schedule. The exact cadence is shown on each integration's detail panel in-app; the table below is the typical default by integration category. Cadences are chosen to balance freshness against source-system load and may be adjusted by the Radius360 team based on observed source behavior.
| Integration type | Default cadence | Why |
|---|---|---|
| Identity (Okta, Entra, Google Workspace) | Hourly | MFA, admin, and access changes are high-signal; hourly catches them without hammering. |
| EDR / XDR (CrowdStrike, SentinelOne, Defender, Sekoia) | 15 minutes | Detections need fast turnaround from alert to governance artifact. |
| SIEM (Splunk, Sentinel, Elastic) | 15 minutes | Same reasoning. High-signal sources get tighter cadence. |
| Cloud posture (AWS, GCP) | Hourly | Configuration changes are usually deliberate. Hourly catches drift without saturating cloud APIs. |
| Vulnerability (Tenable, Rapid7, Qualys) | Daily | Scan cadence is upstream; we sync after typical scan completion windows. |
| Ticketing (Jira, Linear, ServiceNow) | Hourly | Status changes on linked mitigation tasks need near-real-time visibility. |
| Awareness, email, edge (KnowBe4, Proofpoint, Cloudflare) | Daily | Evidence tends to change slowly; daily is plenty for audit coverage. |
Cadences are tunable per-integration on Enterprise plans. Go to Settings, Integrations, pick an integration, Advanced to adjust.
Rate limits we respect
Every integration has a known source-side rate limit. Radius360 is written to stay well below those limits even when syncing large tenants, using two mechanisms:
- Static throttles for sources with published rate limits, with headroom budgeted in so steady-state sync traffic does not approach the source's ceiling.
- Adaptive throttles for any source. When we see a 429 Too Many Requests response, we back off exponentially for that specific endpoint and resume at a slower rate.
The net effect: a Radius360 sync should not cause a source-side rate-limit incident on a normally-sized tenant. If you have alerting on API usage, our traffic will be visible but is engineered to stay below normal alert thresholds.
Retry and backoff behavior
When a sync fails, Radius360 retries with exponential backoff:
- Immediate retry on transient network failures (one attempt, then give up for this cycle)
- On 5xx server errors from the source, retry after 60 seconds, then 5 minutes, then 30 minutes
- On 429 rate-limit errors, respect the source's Retry-After header if provided; otherwise back off exponentially starting at 2 minutes
- On authentication errors (401, 403), do not retry. The credentials are broken and need operator action.
After 3 failed retries within a single scheduled sync window, the integration moves to Error status and waits for the next scheduled sync (or manual retry) before trying again.
Event-driven updates
Some deep integrations support webhooks or event subscriptions instead of polling. When available, Radius360 subscribes to the event stream so certain high-severity events arrive in near real time rather than on the scheduled cadence.
Currently event-driven:
- CrowdStrike detections (via Falcon Streaming API)
- Microsoft Sentinel incidents (via Logic Apps webhook)
- AWS Security Hub critical findings (via EventBridge webhook)
- Sekoia XDR alerts (via webhook)
For these sources, critical events land in Radius360 within 60 seconds of detection, even though the full scheduled sync still runs every 15 minutes for completeness.
Forcing a sync manually
From the integration detail panel, you can click Sync Now to trigger an out-of-schedule sync. This queues a fresh sync and returns immediately; the sync runs in the background.
For a full re-sync (including historical data that the incremental sync would normally skip), use Force Full Sync instead. This takes longer but rebuilds everything from scratch.
Force Full Sync can be expensive
On integrations with large historical windows (SIEM log sources, cloud accounts), Force Full Sync can take hours and generate significant source-side API traffic. Use when you have a specific reason: recovering from a misconfiguration, verifying after a policy change on the source side, or satisfying an audit request.Outbound IP ranges
For customers with IP allowlists on their source systems, the current outbound IP ranges for Radius360 sync traffic are documented in the in-app Settings, Security page and on the public security page. The ranges are stable; any change is announced in release notes at least 30 days before it takes effect.
Email support@radius360.co if you need the current list before connecting a tightly-scoped source system, and we will send the latest allowlist directly.
Related reading: Troubleshooting sync failures, API and webhooks for custom integrations.