Each response of the API is structured according to the same schema. The status property displays the returned HTTP status, while the links property provides useful URI templates (RFC 6570) for navigation. The answer itself is provided via the content property. If an error occurs, the problem property is set and provides useful information about the error.

A problem has four different properties. The type property specifies the type of the problem. In addition, the title property provides a human-readable title and the optional message property contains the error message itself. If the problem is of the type constraint-violations, the optional violations property provides more details about the problem. Such a violation object supplies the two fields field and message.

The API uses only the following status codes:

• The 200 (OK) status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method.

• The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

• The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource.

• The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it.

• 404 The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent.

• The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.

To use the API, a security token must always be sent in the X-AUTH-TOKEN header. This token can be obtained via the authentication API.

All public endpoints start with the prefix /api. These endpoints are documented and stable.

All other endpoints are internal and breaking changes may be introduced at any time.

Most endpoints support pagination. Unless you create a UI, you probably don't need this feature.

The onway director uses the so-called keyset pagination method also called seek method. This method loads the next page relative to an element of the current page. You can navigate forward by requesting the elements that come after the last element of the current page, or backwards by requesting the elements that come before the first element of the current page.

A request to load a page contains the following parameters:

Example:

Assume we have an entity with one field called name. We can load the first page with the request: /api/my-endpoint?size=3.

{
    "status": 200,
    "reason": "OK",
    "content": {
        "hasNext": "YES",
        "hasPrevious": "NO",
        "entities": [
            {
                "name": "A",
            },
            {
                "name": "B",
            },
            {
                "name": "C",
            }
        ]
    }
}

To load the next page we can use the name of the last element as seek identifier: /api/my-endpoint?size=3&seekDirection=FORWARD&seekIdentifier.name=C.

{
    "status": 200,
    "reason": "OK",
    "content": {
        "hasNext": "NO",
        "hasPrevious": "UNKNOWN",
        "entities": [
            {
                "name": "D",
            },
            {
                "name": "E",
            },
             {
                "name": "F",
            }
        ]
    }
}

Authentication API to login and logout.

Provides access to the application version.

Provides access to the customers.

Provides access to the tags.

Provides access to the input templates.

Provides access to the Network Access Groups.

Allows to create, read, update and delete Network Access Accounts.

Allows to create, read, update and delete Systems.

Manage Devices.