Cloudflare Response Integration via API

Purpose

This guide explains how to configure Logsign's Cloudflare Response integration, one of the action integrations available under Settings > Integrations > Responses. Response integrations let a Logsign Incident or Alarm trigger an action on a third-party product, either automatically through an action rule or manually from the incident screen. For Cloudflare, the available actions are blocking and unblocking an IP address, and blocking and unblocking a URL path, on the zone level using Cloudflare's IP Access Rules and Firewall Rules features.

This is a different integration from Cloudflare log collection (the "Cloudflare Integration via API" poller that pulls zone/DNS logs into Logsign, and the separate "Cloudflare Zero Trust" and "Cloudflare R2" pollers). Those read logs. This document covers the Response integration: it writes changes to your Cloudflare zone. Both the poller and the Response integration can reuse the same Cloudflare API Token, but they are configured in different parts of the Logsign UI (Settings > Sources for the pollers, Settings > Integrations > Responses for this one).

Prerequisites

You need admin access to the Cloudflare account or zone you want Logsign to act on, so you can create an API Token, and admin access to Logsign to configure the Responses integration. Reading the integration's Go source (automation/integration/cloudflare/) and its UI manifest (cloudflare.manifest) confirms it authenticates with a Cloudflare API Token sent as an HTTP Authorization: Bearer <token> header on every request, against the base URL https://api.cloudflare.com/client/v4. There is no code path in this integration for Cloudflare's older authentication scheme (the account-wide Global API Key paired with your account email in X-Auth-Email and X-Auth-Key headers); only a Bearer-style API Token is ever sent. This is good news from a least-privilege standpoint: you cannot accidentally end up using the broad, account-wide Global API Key with this integration even if you wanted to, because the integration never sends the headers that key requires.

Step 1: Create a scoped API Token in Cloudflare

Use a scoped API Token, not the Global API Key. A Global API Key grants full access to everything on your Cloudflare account and cannot be limited to a single zone or a single capability; a Token can be scoped to exactly the zone(s) and permissions this integration needs, and can be revoked independently of your account credentials if it is ever exposed.

1. Log in to Cloudflare at https://dash.cloudflare.com with an account that has permission to issue API Tokens for the zone(s) you want Logsign to manage.
2. Click your profile icon in the top right, then My Profile, then the API Tokens tab. (You can also go directly to https://dash.cloudflare.com/profile/api-tokens.)
3. Click Create Token, then Create Custom Token at the bottom of the templates list.
4. Give the token a clear name, for example logsign-response, so it is identifiable later in Cloudflare's audit log.
5. Under Permissions, add two zone-level permissions:
   • Zone > Zone > Read, so the token can list zones (used by the integration's Get Zones method to populate the Zone dropdown described in Step 2).
   • Zone > Firewall Services > Edit, so the token can create and delete IP Access Rules and Firewall Rules (used by Block IP, Unblock IP, Block URL, and Unblock URL).
6. Under Zone Resources, restrict the token to Specific zone and select only the zone(s) you actually want Logsign to be able to block traffic on, rather than All zones. If you plan to use this integration against more than one zone, either add each zone here or, if your account has many zones and this is impractical, select All zones from this account and accept the broader blast radius as a deliberate tradeoff.
7. Click Continue to summary, review the permissions shown, then click Create Token.
8. Copy the generated token immediately. Cloudflare shows it only once; if you lose it, you have to revoke it and generate a new one.

Important: even though the field you paste this into inside Logsign is labeled "Api Key," it must be a Cloudflare API Token from the steps above, not the Global API Key from the older "API Keys" section of the same page. The integration authenticates purely with a Bearer token; a Global API Key pasted into this field will not authenticate, because the integration never sends the X-Auth-Email header that the Global API Key scheme requires alongside the key itself.

Step 2: Configure the integration in Logsign

In Logsign, go to Settings > Integrations > Responses, search for Cloudflare, click Configure, then +Device. Fill in the following fields:

Click Create to save. This is the complete configuration form; the current manifest for this integration exposes only the Api Key field. (The integration's underlying configuration structure also defines an optional outbound proxy URL, but it is not present in the configuration schema/form, so it does not appear as a field here; this was not independently verified by testing the live form.)

There is no Zone ID field on this configuration screen, and that is expected: unlike the Cloudflare data-collection poller, which does ask for a Zone ID and Account ID up front, this Response integration resolves the zone dynamically at action time. When you build an action rule or run a method manually, Logsign calls Cloudflare's GET /zones endpoint behind the scenes (the integration's internal Get Zones method) and shows you a Zone dropdown populated with every zone name your token can see, and you pick the target zone from that list rather than typing an ID anywhere. If the zone you expect is missing from that dropdown, the token's Zone Resources scope in Cloudflare (Step 1) does not include it.

Available Methods

Get Zones

Category: investigation. Returns the list of Cloudflare zones visible to the configured API Token (zone name and zone ID). This method exists mainly to populate the Zone dropdown shown on the four methods below, but you can also run it on its own to confirm which zones the token can currently see.

Block IP

Category: change (Containment). Creates a Cloudflare IP Access Rule on the selected zone with mode block, targeting the given IP address, with the note "Blocked by Logsign." Can be wired into an alarm's action rule for automatic blocking, or triggered manually from an incident.

This value is not sent to Cloudflare as part of the API Access Rule itself; Cloudflare's IP Access Rules have no native expiration field. Based on how the equivalent Expire Time option works on other Logsign block/unblock Response integrations, the expectation is that Logsign's own automation engine schedules a later call to Unblock IP for the same Ip/Zone once the timer elapses when anything other than Permanent is chosen. This scheduling logic lives outside the Cloudflare-specific integration code reviewed for this guide and was not independently re-verified against it; treat Permanent as the option to rely on if precise automatic-expiry timing matters for your use case, and confirm actual expiry behavior in your own environment before depending on it.

Cloudflare's API does not appear, from its own documentation, to reject a duplicate IP Access Rule for an IP address that is already blocked on the same zone; whether calling Block IP twice for the same IP creates two separate rules was not tested live as part of this guide. If in doubt, check the zone's Security > WAF > Tools > IP Access Rules list in the Cloudflare dashboard before re-blocking an address.

Unblock IP

Category: change (Recovery). Removes the IP Access Rule previously created for the given IP address on the given zone. This is the counterpart to Block IP and runs automatically when a block's Expire Time elapses (see the note above). The manifest disables this method for direct use in a new action rule, so in practice it is reached either through automatic expiry of a prior Block IP, or by manually reversing an existing block from within the incident it was triggered from.

Logsign looks up the matching IP Access Rule by IP address on the selected zone and deletes it. If more than one rule exists for the same IP on that zone (for example, if it was blocked more than once outside of the Expire Time flow), only one of them is deleted; which one is not guaranteed by Cloudflare's list ordering. If the address is not currently in the list of IP Access Rules for that zone, this method fails with an error rather than silently succeeding.

Block URL

Category: change (Containment). Creates a Cloudflare Firewall Rule on the selected zone that blocks requests matching the given URL path, described as the URL you entered so Unblock URL can find it again later.

Format warning: the integration builds a Cloudflare Rules expression of the exact form (http.request.uri.path eq "<your value>"). Cloudflare's http.request.uri.path field is only the path portion of the request, for example /wp-login.php; it never includes the hostname/domain and, per Cloudflare's own field reference, is a distinct field from http.host. Enter a path starting with a forward slash, for example correct: /wp-login.php, wrong: example.com/wp-login.php or wrong: https://example.com/wp-login.php. A value that includes the hostname or scheme will create a rule that never matches real traffic, and Cloudflare will not warn you about this at rule-creation time; the rule will simply sit there doing nothing.

Unblock URL

Category: change (Recovery). Removes the Firewall Rule (and its underlying Filter) previously created for the given URL on the given zone. Like Unblock IP, this method is not offered directly when building a new action rule; it is reached through automatic expiry of a prior Block URL or by manually reversing an existing block from an incident.

Logsign looks up the Firewall Rule by its description (the exact Url text from Block URL) on the selected zone, deletes the rule, then separately deletes the underlying Filter object the rule referenced. If no rule matches the description, this method fails with an error rather than silently succeeding.

Notes and Limits

• Only IP and URL-path blocking are implemented. There is no DNS record management, no cache purge, no WAF custom rule (ruleset) management, and no account-level action of any kind in this integration, even though the underlying Cloudflare API supports all of those. If you need those capabilities, they are not currently exposed through this Response integration.
• Blocking happens through Cloudflare's classic, zone-level IP Access Rules and Firewall Rules APIs. Cloudflare's own current documentation for IP Access Rules recommends using its newer WAF custom rules (rulesets) product for new IP- and geography-based blocking instead, though as of this writing Cloudflare has not announced deprecation of the endpoints this integration uses, and they continue to function. If your zone already manages blocking primarily through custom rules, be aware that rules created by this integration live in a separate, older rule set and will not appear alongside them in the newer custom rules UI; check Security > WAF > Tools for IP Access Rules and the classic Firewall Rules list specifically.
• The Zone field on every method is a live lookup against Cloudflare, not a value you type or store in the device configuration. If your API Token's Zone Resources scope changes in Cloudflare (a zone is added or removed from the token), the Zone dropdown in Logsign reflects that on the next call to Get Zones, with no separate step needed on the Logsign side.
• Unblock IP and Unblock URL both work by looking up the existing rule/filter first and deleting it by ID; they do not accept a rule ID directly. If a rule was renamed, edited, or its description changed outside of Logsign (directly in the Cloudflare dashboard), the lookup may no longer find it, and the corresponding Unblock call will fail even though a rule for that IP or URL still technically exists in Cloudflare.
• The integration does not cache or refresh a session; every method call decrypts the stored Api Key and sends it fresh as the Bearer token on that call's requests. If the token is revoked or expires on the Cloudflare side, this is caught on the very next action rather than causing a silent long-running failure.
• There is no built-in retry or backoff in the integration's code for a failed Cloudflare API call. A failed request (network error, permission error, rate limit) surfaces immediately as a failed action; Logsign's own action rule/incident retry behavior, if any, governs what happens next.
• After an Unblock IP or Unblock URL call reports success, it is worth spot-checking the corresponding rule list in the Cloudflare dashboard if you have any doubt, particularly right after a bulk cleanup or scripted run, rather than assuming a successful response always means Cloudflare's own delete request fully completed as expected.

Troubleshooting