OpenWISP Controller API
★ Only Publicly Available OpenAPI DocumentIOTDevice Managementbearer29 EndpointsREST
For Agents
Manage OpenWISP-controlled network devices, configurations, templates, VPN servers, and IPAM subnets through 29 REST endpoints, with bearer token authentication.
Use for: Find all devices currently online in the controller, I need to push a new WireGuard template to every device in a group, Retrieve the configuration of a specific OpenWISP device, Get the next available IP from an IPAM subnet
Not supported: Does not handle radio firmware builds, end-user captive portal authentication, or billing — use for OpenWISP device, template, VPN, and IPAM management only.
Jentic publishes the only available OpenAPI specification for OpenWISP Controller API, keeping it validated and agent-ready. The OpenWISP Controller API exposes REST endpoints for the open-source network management stack used by ISPs, communities, and IT teams to operate fleets of routers, access points, and embedded Linux devices. Agents can register devices, push configuration templates, manage VPN servers, send commands to running devices, and inspect IP address management subnets. Authentication is a bearer token obtained from the OpenWISP token endpoint, scoped to a tenant in the OpenWISP installation.
Install Jentic One Beta
Connect the OpenWISP Controller API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the OpenWISP Controller API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Capabilities
What an agent can do with OpenWISP Controller API.
Register network devices and update their configuration via the controller
Apply configuration templates to a device or device group in bulk
Provision and manage VPN servers used to reach remote devices
Send remote shell commands to devices and inspect command history
Allocate next-available IP addresses from managed IPAM subnets
Inspect device monitoring status and network topology graphs
Use Cases
Patterns agents use OpenWISP Controller API for, with concrete tasks.
★ Fleet provisioning agents
Network operators provisioning new sites can use the OpenWISP Controller API to register devices, attach them to a device group, and apply a configuration template in one workflow. The /controller/device/ POST creates the device, and /controller/template/ exposes the templates that drive its configuration. Agents can run this end-to-end against a fresh OpenWISP install in minutes rather than hand-editing UCI files on every router.
POST /controller/device/ with a name, MAC address, and group, then POST /controller/template/ assignment to apply the standard WireGuard template.
Remote command and recovery workflows
Field-support agents can push commands like reboot, custom shell, or firmware checks to remote devices through /controller/device/{id}/command/. The endpoint accepts a command type and arguments, and command history can be retrieved with the matching GET so the agent can confirm whether the operation reached the device. This replaces SSH-by-hand troubleshooting for a fleet that may sit behind NAT or carrier-grade routing.
POST /controller/device/{id}/command/ with type=reboot and poll the command history endpoint until status returns success.
IP address management automation
Network engineers can use the IPAM endpoints under /ipam/subnet/ to keep address allocation in sync with device onboarding. The /ipam/subnet/{id}/get-next-available-ip/ endpoint returns the next free address inside a subnet, which agents can wire into device-creation flows so every new device receives a routable IP without manual lookup.
GET /ipam/subnet/{id}/get-next-available-ip/ to reserve an IP, then include it when calling POST /controller/device/.
AI agent network operator
Through Jentic, an AI agent can answer operator questions like 'how many devices are offline in region X' by calling /controller/device/ with filters and joining results with /monitoring/device/{id}/. The Jentic vault holds the OpenWISP bearer token per tenant, so multi-tenant managed-service agents can scope each call to the right customer.
Search Jentic for 'list openwisp devices and their monitoring status', call /controller/device/ then /monitoring/device/{id}/, and summarise offline devices.
Key Endpoints
29 endpoints — jentic publishes the only available openapi specification for openwisp controller api, keeping it validated and agent-ready.
METHOD
PATH
DESCRIPTION
GET
/controller/device/
List devices managed by the controller
POST
/controller/device/
Register a new device
POST
/controller/device/{id}/command/
Send a command to a device
POST
/controller/template/
Create a configuration template
GET
/ipam/subnet/{id}/get-next-available-ip/
Reserve the next available IP in a subnet
GET
/monitoring/device/{id}/
Get device monitoring status
GET
/controller/device/
List devices managed by the controller
POST
/controller/device/
Register a new device
POST
/controller/device/{id}/command/
Send a command to a device
POST
/controller/template/
Create a configuration template
GET
/ipam/subnet/{id}/get-next-available-ip/
Reserve the next available IP in a subnet
GET
/monitoring/device/{id}/
Get device monitoring status
Why Jentic?
Three things that make agents converge on Jentic-routed access.
Credential isolation
OpenWISP bearer tokens are stored encrypted in the Jentic vault per tenant. Agents receive an execution context only — the token is injected as Authorization at request time and never enters the agent prompt or logs.
Intent-based discovery
Agents search Jentic with intents like 'list openwisp devices' or 'send a command to a router' and Jentic returns the matching operation under /controller/device/ with its full input schema.
Time to first call
Direct integration: 1-2 days to read the OpenWISP REST docs, set up token auth, and write resilient clients. Through Jentic: under 1 hour — search, load schema, execute.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using OpenWISP Controller API through Jentic.
Why is there no official OpenAPI spec for OpenWISP Controller API?
OpenWISP does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call OpenWISP Controller API via structured tooling. It is validated against the live API and kept up to date. Get started at https://app.jentic.com/sign-up.
What authentication does the OpenWISP Controller API use?
The API accepts an HTTP bearer token obtained from /api/v1/auth/token/ on the OpenWISP host. Through Jentic the token is stored encrypted in the vault and injected as the Authorization header at execution time, so the agent never sees the credential.
Can I push configuration templates to many devices at once with this API?
Yes. Create or update a template under /controller/template/ and assign it to a device group via /controller/device-group/, which applies the template to every device in the group. There is no single bulk endpoint for assigning a template to an arbitrary list of devices — group membership is the standard mechanism.
What are the rate limits for the OpenWISP Controller API?
OpenWISP is self-hosted, so rate limits are governed by the deployment's reverse proxy or Django settings rather than the spec. Treat 429 and 503 responses as backoff signals and tune limits in your own nginx or HAProxy configuration.
How do I send a remote reboot command through Jentic?
Search Jentic for 'send a command to an openwisp device', load the POST /controller/device/{id}/command/ operation, and pass type=reboot in the body. Poll the GET form of the same path for command history and final status.
Does this API include monitoring metrics like CPU and memory?
The /monitoring/device/{id}/ endpoint returns the rolled-up monitoring status for a device. Detailed time-series metrics live in the OpenWISP Monitoring module's separate endpoints, which are not part of this Controller API specification.
GET STARTED