Overview
What this area covers, and what each part needs before it works.
Two related things on the same addresses: attack history, which reads what our network absorbed for your IP space, and firewall, which reads and manages the rules and filters on it. They share a definition of which addresses are yours.
For what the network is doing to that traffic in the first place, see How mitigation works.
| Page | What it covers |
|---|---|
| Attack history | Query attacks by address, prefix, ASN or window; alert on ongoing ones |
| Attack webhooks | Be told when an attack starts and ends, without polling |
| Rules & filters | Create and delete rules and stateful filters on one address, and read state back |
| Groups | One set of rules applied across many addresses |
| Batches & ephemeral rules | Many rules per call, queued jobs, and rules that expire unless bumped |
| Ownership | Which addresses both endpoints treat as yours |
Both areas are gated
Neither is on by default. Attack history needs the Attack History API flag on
your organisation and the attacks.read ability; firewall needs the Firewall
API flag plus firewall.read to read and firewall.manage to write. See
Activation.
Writes are the slow half
Reads are immediate. Firewall writes are accepted synchronously and propagate in 5-10 seconds in the normal case, but can take up to 5 minutes. They are also not atomic across ports, and skip silently on delete — all of which is on the Rules & filters page and is the part most worth reading before you script against it.