Delete a protection rule
ip is required. Rule ids are a global sequence upstream, so the rule is checked to exist
for that address before anything is deleted; anything else is a 404.
Removing a rule does not take the address offline — it falls back to the network's default
filtering. Recreating it is one POST away, which is why this is the one thing a token is
allowed to delete.
apiToken firewall:writeAuthorizationBearer <token>A personal API token: Authorization: Bearer dh_live_…. See Authentication for scopes.
Scope: firewall:write
ruleId*integerid from GET /v1/firewall/rules.
ip*stringOne of your protected addresses, from GET /v1/firewall/ips. Any other address is a 403.
The panel accepted the removal.
application/json- response
ok*booleancurl -X DELETE 'https://api.deluxhost.net/v1/firewall/rules/0?ip=string' \ -H "Authorization: Bearer $DELUXHOST_TOKEN"{ "ok": true}Create a protection rule POST
Creates a rule from one of the presets in `GET /v1/firewall/applications`. **The response carries no rule.** The panel accepts the request and applies it in the background, without returning an id: the new rule appears in `GET /v1/firewall/rules` as `creating` and becomes `working` on its own. Poll that if you need to know it took effect. **Not idempotent, and there is no idempotency key in v1.** A repeated identical rule is refused by the panel as a duplicate — a `400`, not a silent success. Read the rule list before retrying a call whose response you never saw. The advanced fields are only meaningful on the `Custom` application; the presets carry their own tuning and ignore them.
List supported protection applications GET
The catalogue a rule is built from — one entry per protocol-aware filter the network offers. Identical for every account, and the source of the `applicationId` a rule needs.