--- title: "Allowlisting Iframely robots on your network" description: "Recognize and verify Iframely traffic for your bot controls, use transitive trust to target rules at a specific customer, application, or agent." --- # Allowlisting Iframely on your network This page describes how to recognize and verify Iframely traffic for your bot controls, how transitive trust works as we act as a technical intermediary, and how to target rules at a specific customer, application, or agent. It applies identically across all three Iframely agents — [Preview](/docs/about), [Processing](/docs/about-processing), and [Training](/docs/about-training). You can target rules at a specific agent by its User-Agent string; otherwise, the allowlisting steps below are the same for all three. ## Recognize Iframely traffic There are two independent ways to recognize and verify Iframely traffic, in addition to the User-Agent string. ### IP allowlisting and reverse DNS The legacy approach: maintain an allowlist of our IPs, or perform a reverse DNS check on the source IP address. - **Allow our public IP addresses**, as listed: [IPv4](/ips-v4) and [IPv6](/ips-v6). Both lists are populated automatically from our internet gateways — please refresh your copy periodically, or fetch them programmatically. - **If you do reverse DNS lookups**, allow our domain — Iframely traffic resolves to a subdomain of iframely.com. Reverse DNS reliably verifies IPv4 traffic only; for requests arriving over IPv6, use IP allowlisting or Web Bot Authentication instead. ### Web Bot Authentication The current approach: [Web Bot Authentication](https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/). All three Iframely agents sign their requests using this standard, adding cryptographic HTTP message signature headers, so you can verify identity regardless of IP version, without maintaining or refreshing an IP list. Signed requests carry the standard `Signature`, `Signature-Input`, and `Signature-Agent` headers — see Cloudflare's documentation, linked above, for how to verify them. The signature host resolves to iframely.com; we suggest allowlisting that domain. Some customers request that their own Web Bot Authentication signature be used instead of Iframely's. In that case, verifying the request is a matter between you and that customer directly — as a technical intermediary, we're not part of that allowlisting relationship. ## Transitive trust Iframely operates on behalf of many different customers and applications — Iframely is the operator, and each customer using it is a separate end user behind individual requests. As [proposed by Cloudflare](https://blog.cloudflare.com/content-independence-day-ai-options/#experimenting-with-transitive-trust), building this kind of trust requires _"proxy components to disclose information that would otherwise be lost in the proxying process"_. Iframely follows this approach, using the existing header extension defined in [RFC 7239](https://www.rfc-editor.org/info/rfc7239): every Iframely request carries a `Forwarded` header identifying the specific customer or application behind it. We go further still, passing additional information about customer and request intent through the headers described below. ## Iframely HTTP headers Every Iframely request, from any of the three agents, carries this header set: - `Forwarded: for=; use=` — `for` identifies the requesting customer or app, per transitive trust above. `use` reflects declared content use, and is meaningful for the Processing and Training Agents only — see their docs for the values it can take. - `X-Iframely-Request-ID` — a per-request UUID for traceability, useful to reference if you contact us about a specific request. - `X-Iframely-App` — a system-generated identifier for the requesting application, unique across Iframely. - `X-Iframely-Customer: name=; url=` — the customer's self-declared name and URL, when they've provided one. - `X-Iframely-Processing: mode=; use=` — the customer-declared purpose of the request. `mode` is one of `preview | assist | discover | search | ai-input | ai-train`. See [processing modes](/docs/processing-modes) for what each means and what it accesses by default. - `X-Iframely-Contact` — our support contact address, included directly on the request. You can target controls at a specific declared mode, or use `X-Iframely-App` or `X-Iframely-Customer` to apply rules to specific Iframely customers or applications — for example, allowing an agent broadly while restricting one particular application, or the reverse. The same identification is also available via each agent's User-Agent string, through its optional name extension, if User-Agent-based rules are easier for you to manage. ## Contact Please reach out if you have any questions or concerns: [support@iframely.com](mailto:support@iframely.com)