Allowlist Rapidflare's ingestion IP

All Rapidflare ingestion traffic reaches your systems from a single static IP address. If your content sits behind a firewall, VPN, WAF or IP allowlist, add this address so Rapidflare can read it.

The IP address to allowlist

Allow inbound connections from:

34.28.22.66/32

This is a reserved static address that does not change on deploys, restarts or scaling events. It is the only address Rapidflare ingestion connects from.

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 entry. 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.

When you need this

Add the allowlist entry 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 this address does not cover

The allowlist entry applies only to ingestion — the crawling and syncing of your content into Rapidflare. It does 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 entry, 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 34.28.22.66 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

This address is stable and we treat it as a published integration contract. If it ever needs to change, or if we add a second 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.