Skip to main content
The Controller API gives you programmatic access to Controller operations such as configuration updates, status checks, and automation workflows.
Aviatrix does not guarantee that the API surface will remain unchanged between versions. Aviatrix will maintain a changelog of API documentation changes to help you update your integrations when upgrading. See the API changelog for documented changes between versions.

Choose the Right Interface

Use the API when you need imperative control from scripts, CI pipelines, or external platforms. In most Infrastructure as Code workflows, prefer Terraform first. Terraform provides declarative state management, repeatable plans, and safer drift handling. Use direct API calls when Terraform does not cover a required operation or when you need ad hoc or event-driven actions.

Typical API Workflow

Many API integrations follow this order:
  1. Authenticate with POST /v2/api/login.
  2. Capture the returned CID session token.
  3. Send authenticated requests with CID in the Authorization header as cid <CID>.
  4. Re-authenticate and refresh CID after session expiration.
This page walks through that common pattern and provides a reusable example.

Prerequisites

  • A Controller FQDN or IP address, for example, controller.example.com or 192.0.2.10. Do not include a scheme, path, or trailing slash.
  • A user account with permissions for the endpoints you call.

API Request Pattern

Set the Controller FQDN or IP address once. Each example constructs the request URL by adding https:// and the API endpoint path.
1

Authenticate with the login API

Send POST /v2/api/login with username and password.
2

Store the CID from the login response

Extract the session token and store it for subsequent requests.
3

Call API endpoints with the CID

Send CID in the Authorization header as cid <CID>.
4

Refresh the session when needed

If a request returns "return": false, check "reason" and log in again to get a new CID before retrying.

Response Format

Most v2 endpoints use a standard response shape:
  • return: true on success, false on failure.
  • results: response payload on success.
  • reason: failure reason when return is false.

Example Flows