CDN whitelisting

Allow Firmly traffic through your CDN, WAF, bot-management system, or rate limiter. Configure an allow rule only when these controls block Firmly requests. Apply the rule to each staging and production hostname that Firmly will access.

​​ Firmly Connect guidance

Firmly Connect detects the CDN or WAF that protects the merchant domain. The merchant can change the detected provider when the result is not correct.

The wizard includes provider-specific instructions for:

• Cloudflare
• Akamai
• Fastly
• Google reCAPTCHA Enterprise
• CloudFront with AWS WAF
• Other CDN and WAF products

Each guide provides numbered steps and copy controls for rule values. The task remains locked until KYB approval. It is the final merchant action before the Firmly go-live review.

​​ Choose an allowlisting method

Use the first method that your security product supports.

​​ Why request identity is preferred

Firmly runs on distributed edge infrastructure. Web Bot Auth and header-based allowlisting attach identity to each request. Firmly can then use a direct path to your CDN or WAF.

IP allowlisting requires Firmly to route traffic through fixed egress gateways. This adds a network hop and can add latency.

Request-level identity has these benefits:

• It preserves direct routing from Firmly’s edge to your edge.
• It continues to work when a reverse proxy changes the source IP address.
• It keeps access control independent of Firmly’s network topology.
• It avoids routing all merchant traffic through fixed egress gateways.

​​ Web Bot Auth

Firmly signs outbound requests with HTTP message signatures. Your edge verifies the signature with Firmly’s published public key. This method does not use a shared secret.

Cloudflare lists FirmlyAI Bot Open external link in its verified bot directory. Cloudflare can verify the signed request and classify it as FirmlyAI Bot.

​​ Cloudflare setup

1. Confirm that your Cloudflare plan can create a rule for the FirmlyAI Bot identity.
2. Create an allow or skip policy for verified FirmlyAI Bot requests on the required hosts and routes.
3. Keep your normal security policy for unsigned requests and requests with an invalid signature.
4. Do not remove or rewrite the Signature-Agent, Signature-Input, or Signature headers before Cloudflare verifies the request.
5. Tell Firmly which domains and environments use this policy. Firmly will send a signed request and verify access.

If your Cloudflare plan cannot select the FirmlyAI Bot identity, use header-based allowlisting.

See Cloudflare Web Bot Auth for plan and verification details.

​​ Other edge providers

Your CDN, WAF, API gateway, or origin must support Web Bot Auth or RFC 9421 HTTP message signatures. It must use the public key identified by Signature-Agent to verify Signature-Input and Signature.

Keep your normal security policy for unsigned requests and requests that fail verification.

​​ Header-based allowlisting

Firmly and the merchant agree on a unique shared-secret value. Firmly sends the value in the x-ac-auth request header.

The exact header name and value shown in Firmly Connect are authoritative for your integration. Do not use an example value from documentation.

Some Firmly Connect guides generate a new example secret when the page loads. If you use this value, copy it once. Use the same value in the merchant rule and in the secure handoff to Firmly. A page reload creates a different example and does not change the value already configured at either side.

1. Get the merchant-specific value from Firmly through the agreed secure channel.
2. Create a rule that matches the complete x-ac-auth value. The value is case-sensitive.
3. Configure the matching request to skip only the controls that block Firmly. These controls can include managed WAF rules, bot checks, and rate limits.
4. Put the allow rule before conflicting block and rate-limit rules.
5. Limit the rule to the required hostnames and routes when your security product supports this restriction.
6. Tell Firmly that the rule is ready. Firmly will send a request with the same value and verify access.

Do not publish the shared secret in documentation, source code, or a support ticket.

​​ IP allowlisting

Use IP allowlisting only when Web Bot Auth and header matching are not available.

1. Add all four IPv4 addresses to the allowlist.
2. Add both IPv6 ranges when your endpoint and security product support IPv6.
3. Apply the rule at the layer that receives Firmly’s source address.
4. Do not trust an arbitrary forwarded-IP header when a CDN replaces the source address.
5. Limit the rule to the required hostnames and routes when possible.
6. Tell Firmly which domains and environments use the rule. Firmly will route a test through fixed egress and verify access.

Always check this page for the current IP list before you configure a new environment or production release.

​​ Complete the Firmly Connect task

After you configure the selected method:

1. Ask Firmly to run an access test.
2. Confirm that the request reaches the merchant endpoint without a WAF block, bot challenge, or rate-limit response.
3. Confirm that requests without valid identity continue through the normal security policy.
4. Select I’ve completed the configuration in Firmly Connect.
5. Mark the task complete.

Firmly Connect records the action in the audit log and unlocks the next onboarding task.

​​ Verification criteria

Firmly checks these results before integration testing continues:

• The selected method identifies Firmly traffic.
• Invalid or unidentified traffic does not use the allow rule.
• Catalog and cart tests run without intermittent access failures.
• The rule covers each required staging and production hostname.

​​ Related

• Onboarding wizard — the complete merchant onboarding sequence
• Going Live — the final review and approval task
• Audit logs — the recorded completion event