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.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fopenwisp.org%2Fopenwisp" | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fopenwisp.org%2Fopenwisp" | sh
jentic register       # connects your agent to your Jentic One instance

Jentic 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.

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

GET STARTED

Start building with OpenWISP Controller API

Explore with Jentic One

View OpenAPI Document

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 One instance 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/

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/

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?

What agents get from Jentic-routed access to this vendor.

Setup

Wiring the OpenWISP Controller API by hand means pointing at your own controller host, sending its bearer token on every call, and keeping device, template, VPN, and IPAM routes straight. Through Jentic you install once, import the OpenWISP Controller API from the API Directory, store the token once, and your agent calls it.

Permission scoping

OpenWISP puts the resource id in the URL path (/controller/device/{id}/...), so a rule can pin your agent to one device: it can read that device's monitoring data and nothing else. You choose the operations it may call, so actions like sending a command or creating a template are not included unless you add them.

Credential isolation

Your OpenWISP bearer token is stored once, encrypted, by your own Jentic One instance and injected as the Authorization header at execution time. It never enters the agent's prompt, logs, or context.

Intent-based discovery

Agents search Jentic by intent such as 'list openwisp devices' or 'send a command to a router', and Jentic returns the matching operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

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 with Jentic One, the self-hosted execution layer.

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.

Can I limit what my agent is allowed to do with the OpenWISP Controller API?

Yes. Jentic One runs self-hosted, so your own rules decide which OpenWISP operations and credentials the agent may use. Because OpenWISP puts the resource id in the URL path, such as /controller/device/{id}/, you can pin the agent to a single device so it reads that device's monitoring data and nothing else. You also choose the operations it may call, so write actions like POST /controller/device/{id}/command/ or creating a template under /controller/template/ stay off limits until you add them.

OpenWISP Controller API

Name: OpenWISP Controller API
Brand: OpenWISP Controller API
Availability: InStock

AI ReadinessFoundational (C+)59/100

See full scorecard

Agent-ready OpenAPI document · curated by JenticIOTDevice Managementbearer29 EndpointsREST

Know of an official OpenAPI document? Contribute it →

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.

Jentic One on Github View OpenAPI Document

Show dimension breakdown

Foundational Compliance

Base layer of spec validity and structural soundness.

Grade: C-Signals: 4

87%

Lint Results

Aggregated quality score from linter diagnostics, weighted by severity.

100%

Resolution Completeness

Percentage of `$ref` references that resolve successfully.

Specification Validity

Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).

21%

Structural Integrity

Structural correctness score based on schema issues using logarithmic dampening.

Developer Experience & Jentic Compatibility

Clarity, completeness, and ingestion readiness for developers and tooling.

Grade: B-Signals: 4

Example Density

How richly the API is illustrated with examples.

100%

Example Validity

Percentage of examples that conform to their schemas.

50%

Response Coverage

Percentage of operations with complete response definitions (success, client error, server error).

93%

Tooling Readiness

Health of API ingestion, bundling, and resolution within Jentic pipelines.

AI-Readiness & Agent Experience

Semantic breadth, depth, and agent comprehension for AI systems.

Grade: C-Signals: 4

42%

Description Coverage

Coverage of descriptions across API elements.

Error Standardization

Coverage of RFC 9457 Problem Details for error responses.

100%

OperationId Quality

Coverage, uniqueness, and casing consistency of operationIds for AI inference.

66%

Summary Coverage

Coverage of summaries across operations/tags/info.

Agent Usability

Functional utility, complexity comfort, and AI orchestration readiness.

Grade: A+Signals: 1

94%

Complexity Comfort

Agent comfort level based on API operational and structural complexity.

Security

Trust, risk posture, and security compliance.

Grade: CSignals: 1

55%

Authentication Strength

Average quality of security schemes based on authentication method strength (weakest link for OAuth2).

AI Discoverability

Findability, semantic richness, and reasoning readiness.

Grade: C-Signals: 1

51%

Descriptive Richness

Clarity and depth of descriptions across API elements.

Connect the OpenWISP Controller API to your agent

Capabilities

Start building with OpenWISP Controller API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs

OpenWISP Controller API

Jentic AI Readiness Score

OpenWISP Controller API

Foundational Compliance

Lint Results

Resolution Completeness

Specification Validity

Structural Integrity

Developer Experience & Jentic Compatibility

Example Density

Example Validity

Response Coverage

Tooling Readiness

AI-Readiness & Agent Experience

Description Coverage

Error Standardization

OperationId Quality

Summary Coverage

Agent Usability

Complexity Comfort

Security

Authentication Strength

AI Discoverability

Descriptive Richness