Neurowall exposes a REST API (and a gRPC alternative) for rules, threat feeds, DDoS config, and network settings — so firewall management fits into the same CI/CD, IaC, and scripting workflows as the rest of your infrastructure.
Traditional firewall appliances gate every change behind a GUI and a change-control ticket. Neurowall's API-first design means rule changes, blocklist updates, and DDoS threshold tuning can be driven the same way you already manage the rest of your infrastructure — version-controlled, reviewed in a pull request, and applied by a pipeline.
Three roles — admin, operator, viewer — control who can read vs. mutate state, so automation accounts get exactly the access they need.
Scoped API keys (X-API-Key header) skip the login round-trip entirely for automation — or use standard JWT bearer tokens if a session-based flow fits your setup better. Both work with any HTTP client, CI runner, or IaC provider without custom SDKs.
The policy trace/simulation endpoints test a rule change's before/after impact — including an optional real-kernel verification path — before it touches production traffic.
Use REST for scripting and CI simplicity, or the gRPC service with TLS for high-performance integrations.
Issue a scoped API key from the admin UI or database-backed key store, and store it as a CI secret — never in a script or repo. No login round-trip needed for automation.
List active rules before making a change — useful as a pre-change diff in CI.
Run the proposed rule through policy trace simulation before it's applied — catch conflicts and shadowed rules early.
Create the rule via the CRUD endpoint. The change syncs to the fast filter and firewall rules automatically.
Fetch the single-rule view to confirm which enforcement layers actually verified the change.
| Group | Covers |
|---|---|
| Rules | CRUD on firewall rules, active-rule listing, kernel handle lookups |
| Trace & Simulation | Before/after policy simulation across both enforcement layers, optional live verification |
| Threat Intel | Blocked-IP management, threat feed status |
| DDoS Config | Rate limit thresholds, protection module toggles |
| Network | Interfaces, routes, WAN failover/load-balance policy, NAT intents |
| Audit | Immutable audit log queries and retention control |
| Rule Export | NIST SP 800-41 rule-review column format for compliance reporting |
Most traditional appliances — and even some "API-enabled" ones — treat the API as an afterthought bolted onto a GUI-first product. The difference shows up the moment you try to manage more than one box.
| Common pattern | Where it breaks down |
|---|---|
| GUI-first appliances with a thin API | The API often only covers a fraction of what the GUI can do — bulk rule import, DDoS tuning, or export may be GUI-exclusive, forcing a human back into the loop for exactly the operations automation needs most |
| Vendor-specific config languages | Proprietary CLI syntax (not REST, not standard SQL/YAML) means every integration is custom-built and brittle to firmware upgrades — there's no ecosystem of existing tools to reuse |
| No dry-run / simulation capability | A scripted rule push either works or breaks production — there's no way to test a change's real impact before it's live, so teams either skip automation for risky changes or accept the blast radius |
| Change tracking bolted on after the fact | Audit logs that only capture GUI actions miss automated changes entirely — the exact changes you'd most want traced during an incident review are invisible |
Every capability the UI exposes — rule CRUD, DDoS config, threat intel, audit queries, compliance export — is reachable through the same REST API, not a stripped-down subset.
Policy trace simulation was part of the core design, not a feature added after customers asked for safer automation — see Automate Your Firewall for the guardrail patterns this enables.
API keys, JWT bearer tokens, and RBAC work with any HTTP client or CI runner you already use — no proprietary SDK, no vendor lock-in to a specific automation platform.
API-driven mutations are captured by the same immutable audit log as manual changes, with the calling identity attached — automation doesn't create a blind spot in your audit trail.