How do I allow AccessLint through a WAF or bot protection?

AccessLint monitors your site by driving a real headless browser through the journeys you configured. To a WAF or bot-detection service, that traffic can look like an unwanted bot, and a block stops your monitoring before it ever reaches your app.

AccessLint never tries to sneak past bot protection. It identifies itself honestly on every request, so you can let it through with one rule. This page covers what the traffic looks like, how to allowlist it in common setups, and how to verify a request really came from us.

What traffic to expect

User agents. AccessLint sends two, and it helps to know both, because they do different jobs.

Flow runs (the monitoring traffic this page is mostly about) send:

Mozilla/5.0 (compatible; AccessLintFlows/1.0; +https://app.accesslint.com/flows)

Everything else that touches your origin sends:

Mozilla/5.0 (compatible; AccessLintBot/1.0; +https://app.accesslint.com/bot)

AccessLintBot covers domain verification, the free public scanner, and robots.txt fetches. This matters when you write a rule: a rule that matches only AccessLintFlows will still block domain verification, so you can end up unable to verify a domain even though your flow traffic is allowlisted. The URLs in each string point to our public bot documentation.

Identifying header. Flow runs also carry a header unique to your domain:

X-AccessLint-Id: <your domain's id>

The value is a public identifier, not a secret. It is only sent to your verified hostname and its subdomains, never to third-party origins your pages happen to load from. Note that this header is specific to flow runs: AccessLintBot traffic, including domain verification, does not carry it, which is the other reason a header-only rule can leave verification blocked.

Behavior. Traffic is low and predictable: a scheduled run per configured flow (daily or weekly), plus an optional run right after your own deploys if you set up a deploy trigger. It only ever visits domains whose ownership you proved during domain setup. It is not a crawler, and it does not visit sites you haven’t configured.

Source IPs. Requests come from cloud infrastructure with dynamic IPs, so there is no stable IP range to allowlist. Use the header or the user agent instead.

Find your domain’s header value

Open Domains from your dashboard and select the domain.
Expand the Behind Cloudflare or a WAF? Allowlist AccessLint section.
Copy the value shown under Header to allowlist.

Allowlist in Cloudflare

Create a WAF custom rule that skips bot protection for requests carrying your header value:

In the Cloudflare dashboard, go to Security → WAF → Custom rules → Create rule.
Set the action to Skip.
Match on the header: Field Header, header name X-AccessLint-Id, operator equals, and paste your domain’s value. As an expression:

http.request.headers["x-accesslint-id"] eq "<your domain's id>"

Choose which of Cloudflare’s protections to skip for matching requests (at minimum, the bot-management and managed rules that were blocking the runs).

Your domain’s settings page shows this expression prefilled with your actual value, ready to copy.

Allowlist in other WAFs and firewalls

Akamai, AWS WAF, Fastly, Imperva, DataDome, and most other providers support the same idea under different names: an allow, skip, or exception rule matched on a request header. Create one that matches X-AccessLint-Id equal to your domain’s exact value.

Two things to get right, whatever the provider:

Match the exact value, not just the header’s presence. The header name is public, so a presence-only rule would let anyone inherit the bypass by sending the same header name. Value-equality keeps the rule scoped to traffic aimed at your domain.
Cover your subdomains. The header is sent to your verified hostname and everything under it, so if a monitored journey crosses a subdomain (say, from example.com to checkout.example.com), the rule needs to apply there too.

If your WAF can only match on the user agent, allowlist the exact AccessLintFlows/1.0 string above instead. That works, but it permits all AccessLint traffic rather than only requests scoped to your domain, so the header rule is preferred where possible.

Cryptographic verification with Web Bot Auth

Headers and user agents can be copied by anyone. For providers that verify bot identity cryptographically, AccessLint also signs its requests using HTTP Message Signatures (RFC 9421, the “Web Bot Auth” pattern) with an Ed25519 key.

Signed requests carry three additional headers:

Signature-Input: what was signed and with which key
Signature: the signature itself
Signature-Agent: the identity doing the signing, as a structured-field dictionary member keyed to the signature, so the value reads sig1="https://app.accesslint.com" rather than a bare URL

Our public keys are published, and rotated, at a standard key directory:

https://app.accesslint.com/.well-known/http-message-signatures-directory

WAFs and bot-management products that support Web Bot Auth (Cloudflare’s verified-bots program, for example) can verify these signatures against the directory automatically, which proves a request is genuinely from AccessLint no matter what its headers claim. If your provider supports signature-verified bots, that verification can replace the manual header rule entirely. If not, the header rule above is the way to go, and the signature does no harm.

robots.txt

AccessLint honors your robots.txt Disallow rules, including for Flows. A path you disallow is not fetched, even on a domain you have verified. Flows fails closed here: if we cannot decide that a path is allowed, we do not request it.

Match us with either of these user-agent tokens:

AccessLintFlows for monitoring runs
AccessLintBot for the free scanner and domain verification

A bare User-agent: AccessLint group works as an umbrella and binds both.

This bites most often on staging sites, where a blanket Disallow: / is common. That rule stops your flows too. If you want monitoring to run there, readmit AccessLint with a group naming it:

User-agent: AccessLintFlows
Allow: /

One directive we do not observe is Crawl-delay. A flow is a single bounded session of at most 25 page navigations, run once a day, so it generates none of the sustained load that directive exists to throttle.

If a step is stopped this way, the run report says the destination’s robots.txt disallows fetching it and that the request was not made. That is a different failure from a WAF block: nothing was sent, so no allowlist rule will fix it. Change robots.txt instead.

Troubleshooting: a run appears blocked

When a run is stopped by bot protection, AccessLint tells you rather than reporting a misleading failure. In the run’s results, the failed step shows a notice that the destination appears to be blocking the request (bot detection or a WAF), with a link straight to your domain’s allowlist section. Internally this is the bot_blocked failure code, and it triggers when the page responds with a 403 or 429 status or a recognizable bot-challenge response.

If you see it:

Add the allowlist rule for your provider as described above, matching your domain’s exact X-AccessLint-Id value.
Re-run the flow (or wait for the next scheduled run). A successful run clears the state.
Still blocked? Check that the rule matches the exact header value, that it covers every subdomain the journey touches, and that the Skip action includes the specific protection that was blocking (in Cloudflare, bot-management rules and managed rules are separate toggles).

If instead the notice says robots.txt disallows the destination, that is not a WAF problem and no allowlist rule will clear it. See robots.txt above.

Two caveats worth knowing. The signal is deliberately conservative: a genuine 403 from your own app (an expired session, a permissions change) can look identical to a WAF block, so treat “appears blocked” as a strong hint, not a certainty. And a block can appear mid-journey: a flow can pass its early steps on public pages and only hit the wall on a protected one, so the notice may show up on a later step even when the first page loads fine.

Questions, or does something here not match what you’re seeing? Email support@accesslint.com.