Allowlist Rapidflare's ingestion IPs

Rapidflare ingestion traffic reaches your systems from a small set of static IP addresses. If your content sits behind a firewall, VPN, WAF or IP allowlist, add all of these addresses so Rapidflare can read it.

The IP addresses to allowlist

Allow inbound connections from all of the following:

34.28.22.66/32
34.30.154.174/32
34.41.228.67/32
35.255.80.253/32

These are reserved static addresses that do not change on deploys, restarts or scaling events. Ingestion may connect from any of them, so allowlist all four rather than only the ones you currently see in your logs.

* Inbound to your systems, outbound from Rapidflare.

Rapidflare uses Nango, a third-party integration platform, for specific integrations. The following IP addresses need to be allow-listed additionally to support those integrations:

52.34.139.153/32
54.69.127.183/32
44.247.133.183/32
52.26.211.56/32

Use it alongside authentication, not instead of it

An IP allowlist is a network control, not an authentication mechanism. It governs whether a connection can reach you at all; it does not establish who is on the other end. Source addresses on the public internet are visible to every server they reach and can be forged in some circumstances, so we recommend against granting access to content on the basis of source IP alone.

Keep your normal access controls in place alongside the allowlist entries. Rapidflare authenticates to your systems with the credentials you configure on the source, and the network rule simply opens the path for that authenticated connection to arrive.

If you want to verify the identity of crawl traffic itself — rather than just open a network path for it — Rapidflare also signs every crawl request cryptographically. See Crawler Verification.

When you need this

Add the allowlist entries when the content you want ingested is not openly reachable on the public internet. Common cases:

• Self-hosted knowledge bases — Confluence Data Center/Server, on-premise SharePoint, or any wiki behind a corporate firewall. See the Confluence integration guide for the connection steps themselves.
• Documentation portals behind a WAF — Cloudflare, Akamai, AWS WAF and similar services that challenge or block unrecognised clients.
• Staging or pre-release sites — content gated by IP so it is not publicly indexable.
• Rate-limited origins — sites that throttle by source IP. Allowlisting Rapidflare exempts ingestion from limits meant for anonymous traffic.

You do not need this for cloud-hosted sources you connect through OAuth, such as Confluence Cloud, Google Drive or SharePoint Online. Those authenticate as an app rather than by network origin.

What these addresses do not cover

The allowlist entries apply only to ingestion — the crawling and syncing of your content into Rapidflare. They do not apply to:

• Traffic from your end users' browsers to an embedded Rapidflare widget. That traffic originates from your visitors, not from Rapidflare. To restrict widget usage, use API key domain allow-listing described in Widget Security.
• Traffic your team's browsers send to the Rapidflare admin dashboard.

How to verify it is working

After adding the allowlist entries, trigger a sync from the Sources section of your admin dashboard and check the ingestion status. If the source still fails, the request is usually being stopped before it reaches your origin. Check in this order:

1. The rule is applied to the public-facing layer — the CDN, WAF or load balancer — not only to the origin server behind it.
2. The rule covers HTTPS on port 443, not just port 80.
3. No separate bot-mitigation or geo-blocking rule is refusing the request after the IP rule allows it.

Your access logs are the fastest way to confirm: a request from one of the four addresses above reaching your origin means the network path is open, and any remaining failure is an authentication or permissions issue rather than a firewall one.

Change notifications

These addresses are stable and we treat them as a published integration contract. If they ever need to change, or if we add another address, Rapidflare notifies affected customers in advance so allowlists can be updated before any traffic shifts. Ingestion is never silently moved to a new address.

If you need this confirmed in writing for a security review, contact your Rapidflare representative.