Overview: NGINX Instance Manager REST API

Legacy 'nms' references
Some commands, file paths, and configuration references still use nms due to the ongoing transition from NGINX Management Suite (NMS) to NGINX Instance Manager (NIM). These will be updated in future releases.

Introduction

NGINX Instance Manager provides a REST API that uses standard authentication methods, HTTP response codes, and verbs. You can use the API to manage both NGINX Instance Manager and the NGINX instances running on your systems.

Object model

The NGINX Instance Manager REST API allows you to manage both NGINX Instance Manager and NGINX instances programmatically. The API provides the following features:

• View metrics and information about data plane host systems and NGINX instances.
• View and edit NGINX configurations.
• Save NGINX configurations for future deployment.
• Analyze saved and current configurations for syntactic errors.
• Publish configurations to NGINX instances.
• Scan the network to find unmanaged NGINX instances.
• Manage certificates.
• Create users, roles, and role permissions to manage RBAC.

API reference documentation

You can access the NGINX Instance Manager API documentation from the web interface:

1. Log in to the FQDN of your NGINX Instance Manager host.
2. Select API Documentation from the Launchpad menu.
3. On the left menu, select NIM and Platform API.

Usage

You can use tools such as curl or Postman to interact with the NGINX Instance Manager API.

You can find the NGINX Instance Manager API URLs in the following format: https://<NMS_FQDN>/api/platform/<API_VERSION>.

Note:
When making API calls by using curl, Postman, or any other tool, include your authentication information with each call. Also include a -k to bypass TLS/SSL verification.

Alternatively, in the API Reference docs, you can also use the “Try it Out” function. Since you’re already logged into the NGINX Instance Manager platform, the “Try it Out” function automatically includes authentication credentials.

To do so, take the steps below:

1. Select the endpoint and action that you want to send. For example: POST /infrastructure/workspaces.
2. Select the Try it Out button.
3. If the endpoint accepts parameters, replace the placeholder examples in the request body with your desired values.
4. Select the Execute button to send the request.
5. When the request completes, the response appears in the user interface.

Authentication

To use the NGINX Instance Manager API, you need to use one of the following authentication methods:

• Basic authentication
• JSON Web Token (JWT)

Basic authentication

To use basic authentication for API requests, include your base64-encoded credentials as a “Basic” token in the “Authorization” header. To create the base64-encoded credentials, run the following command:

echo -n <username>:<password> | base64

Once you’ve generated the credentials, you can include them in your API request. Here’s how to do it with curl:

curl -X GET "https://<NIM_FQDN>/api/platform/<API_VERSION>/systems" -H "Authorization: Basic <base64_encoded_credentials>"

In this example, replace <NIM_FQDN> with your NGINX Instance Manager’s fully qualified domain name and <API_VERSION> with the API version you want to use.

Security consideration
While basic authentication is an option for API requests, it comes with security risks: credentials are sent as base64-encoded text, which is not secure encryption. If the data is intercepted, the encoding can be easily reversed. For production environments, where security is critical, we strongly recommend switching to OpenID Connect (OIDC).

JSON Web Token

If your organization is using OIDC, you will be prompted to log in with your Identity Provider the first time you attempt to reach an API. After authenticating, you can request a JWT to use in subsequent API calls.

Note:
The means of requesting a token varies according to the Identity Provider; if you’re not sure which provider your organization uses, check with your system administrator or technical support team.

Once you have a JWT, set it up as a “Bearer” using the “Authorization” request header field, as shown in the example below.

curl -X GET "https://<NIM_FQDN>/api/platform/<API_VERSION>/systems" -H "Authorization: Bearer <access token>"

Note:

For security, follow these practices with JSON Web Tokens (JWTs), passwords, and shell history:

1. JWTs: JWTs are sensitive information. Store them securely. Delete them after use to prevent unauthorized access.

2. Shell history: Commands that include JWTs or passwords are recorded in the history of your shell, in plain text. Clear your shell history after running such commands. For example, if you use bash, you can delete commands in your ~/.bash_history file. Alternatively, you can run the history -c command to erase your shell history.

Follow these practices to help ensure the security of your system and data.

Errors and response codes

NGINX Instance Manager uses standard HTTP response codes to indicate whether an API request succeeds or fails. Codes in the 2xx range mean the request succeeded. Codes in the 400 range mean the request failed due to the reason(s) indicated in the response message. Common reasons for 4xx responses are:

• Requests where required information is missing.
• Lack of or incorrect authentication credentials.
• Requests that refer to resources that do not exist or are in use by other resources.

HTTP Status Codes

Encoding

The NGINX Instance Manager API expects and returns JSON-formatted data by default.

All JSON data must be encoded using UTF-8. If you don’t specify a media type in an API call, the API uses application/json by default.

Pagination

Top-level NGINX Instance Manager API endpoints support fetching information about multiple resources (“lists”). These requests can return large data sets (for example, GET /events and GET /instances). You can control the size of the data set returned and navigate through pages by sending additional calls.

Parameters

Versioning

Each major version of the NGINX Instance Manager API is backward-compatible with previous releases of the same version. Any backward-incompatible changes result in a new major version.

The version is represented in the <version> part of the API URI.

For example, to use a v2 API, send requests to:

https://<NIM>/api/platform/v2

When a new version is required, we release it for the entire API. You won’t see a mix of v1 and v2 objects in the same API.