API Reference

Introduction

The OPNsense API calls are structured in the form:

https://opnsense.local/api/<module>/<controller>/<command>/[<param1>/[<param2>/...]]

There are two HTTP verbs used in the OPNsense API:

  • GET Retrieves data from OPNsense

  • POST Creates new data, updates existing data or executes an action

The body of the HTTP POST request and response is an ‘application/json’ object.

The $key and $secret parameters are used to pass the API credentials using curl. You need to set these parameters with your own API credentials before using them in the examples:

key=w86XNZob/8Oq8aC5r0kbNarNtdpoQU781fyoeaOBQsBwkXUt
secret=XeD26XVrJ5ilAc/EmglCRC+0j2e57tRsjHwFepOseySWLM53pJASeTA3

Note

When using Postman to test an API call, use the ‘basic auth’ authorization type. The $key and $secret parameters go into Username/Password respectively.

Note

Always make sure the owner of the key is authorized to access the resource in question, the “Effective Privileges” set on the user shows which resources are accessible. (Edit reveals the endpoints assigned to each resource).

ACL’s are explained in development/components/acl).

Required parameters and expected responses

Our auto-generated api documentation can only collect endpoints and their most likely call method (GET, POST), Since almost 99% of our endpoints are actually being used by the gui, it’s not very complicated to find their parameters, you just need a browser and open an inspect pane. Calls being executed from the gui can easily be found by filtering the requests starting with /api/.

For exampe, when looking at the search grid in System ‣ Diagnostics ‣ Services, pressing the reload button will execute a POST to https://my.firewall/api/core/service/search containing the following raw json data:

{"current":1,"rowCount":7,"sort":{},"searchPhrase":""}

And returns a structure similar to:

{
    "total": 10,
    "rowCount": 7,
    "current": 1,
    "rows": [
        {
        "id": "configd",
        "locked": 1,
        "running": 1,
        "description": "System Configuration Daemon",
        "name": "configd"
        },
        ....
    ]
}

A lot of endpoints use the same shared model classes underneath and will thus look quite similar. If classes are bound to a model, the documentation will point to it. Here you can find the standard types to expect, without specific application specific validations.

When more detailed information is needed, best read the Architecture documentation to understand how different areas of the system interact.

Business edition API

The business edition comes packed with some additional features which could also be used for integration purposes from third-party applications. The most relevant ones will be explained in this section.