Illumio REST APIs 26.x

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "required": [
    "object_limits_state"
  ],
  "properties": {
    "object_limits_state": {
      "description": "States of all Container related object limits",
      "type": "array",
      "items": {
        "description": "Resolution state of specific object limit",
        "type": "object",
        "required": [
          "limit_type",
          "state"
        ],
        "properties": {
          "limit_type": {
            "description": "Type of the Object limit",
            "type": "string"
          },
          "state": {
            "description": "State of object limit enforcement",
            "type": "string"
          }
        }
      }
    }
  }
}

New API: Get Containers Cluster State

GET /orgs/:xorg_id/container_clusters/state

This new schema contains the states of all container-related object limits in the required property object_limits_state. Each item in the array describes one object limit using two required properties: limit_type, the type of object limit, and state, the current enforcement state of that limit.

Use this API to check the object limits that apply to container clusters. The response lists each container-related object limit, with its type (limit_type) and its current enforcement state (state).

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "required": [
    "key",
    "soft_limit",
    "hard_limit"
  ],
  "properties": {
    "key": {
      "description": "Object type key",
      "type": "string"
    },
    "soft_limit": {
      "description": "Soft limit for number of objects of this type; -1 means no limit",
      "type": "integer",
      "minimum": -1
    },
    "hard_limit": {
      "description": "Hard limit for number of objects of this type; -1 means no limit",
      "type": "integer",
      "minimum": -1
    },
    "usage_count": {
      "description": "Current usage for this object type in this org. Present only when the usage_count query parameter is set",
      "type": "object",
      "required": [
        "count",
        "updated_at"
      ],
      "properties": {
        "count": {
          "description": "Number of objects of this type in this org, or 'n/a' when usage of this object type cannot be counted",
          "oneOf": [
            {
              "type": "integer",
              "minimum": 0
            },
            {
              "type": "string"
            }
          ]
        },
        "updated_at": {
          "description": "Timestamp when this count was taken. Counts are cached, so this can be older than the time of the request; null when the count is 'n/a'",
          "type": [
            "string",
            "null"
          ],
          "format": "date-time"
        }
      }
    }
  }
}

New API: Get object limits

GET /orgs/:xorg_id/object_limits returns the soft and hard limits for each object type in your organization. To also get the number of objects currently in use, add the usage_count query parameter.

Use this API to see your organization’s object limits. These are the soft and hard limits on how many objects of each type you can have, such as workloads or labels. A value of -1 means there’s no limit.

To see current usage along with the limits, add the query parameter usage_count=true. Each object type then includes a usage_count object with the current count and the time the count was taken. Counts are cached, so updated_at can be earlier than your request. If usage for an object type can’t be counted, count is "n/a" and updated_at is null.

You can get all limits at once, or get the limit for one object type by adding its key to the path, for example object_limits/total_workloads.

If a create or edit request would exceed a hard limit, the API returns HTTP 406 with the token object_limit_hard_limit_reached.

[
    {
        "key": "active_agents_per_pce",
        "soft_limit": 200,
        "hard_limit": 250,
        "usage_count": {
            "count": 0,
            "updated_at": "2026-08-17T05:54:07.565Z"
        }
    },
    {
        "key": "interfaces_per_agent",
        "soft_limit": 32,
        "hard_limit": -1,
        "usage_count": {
            "count": 0,
            "updated_at": "2026-08-17T05:54:07.571Z"
        }
    },
    {
        "key": "services_per_agent",
        "soft_limit": 160,
        "hard_limit": 200,
        "usage_count": {
            "count": 0,
            "updated_at": "2026-08-17T05:54:07.576Z"
        }
    },
    {
        "key": "total_labels",
        "soft_limit": 20000,
        "hard_limit": 25000,
        "usage_count": {
            "count": 13,
            "updated_at": "2026-08-17T05:54:07.578Z"
        }
    },
======================================================

{
    "key": "total_workloads",
    "soft_limit": 1000,
    "hard_limit": 1250,
    "usage_count": {
        "count": 5,
        "updated_at": "2026-08-17T05:54:07.698Z"
    }
}

{"key":"total_workloads","soft_limit":1000,"hard_limit":1250}

{
  "properties": {
    "services": {
      "properties": {
        "open_service_ports": {
          "items": {
            "properties": {
              "process_short_name__added": {
                "description": "The last segment of process_name, without the leading path",
                "type": "string"
              }
            }
          }
        }
      }
    }
  }
}

New optional read-only property: process_short_name

In GET /orgs/:xorg_id/workloads, each entry in services.open_service_ports can now include process_short_name: the process name without its path. For example, if process_name is /usr/sbin/sshd, process_short_name is sshd.

The new property added in 26.5 process_short_name is an optional string field inside each entry of services.open_service_ports. Each entry describes one listening port that the VEN reported for the workload. The field holds the executable name without its directory path. It is derived from process_name, which already holds the full path.

The property helps with readability and matching. You can match the same process across workloads even when it’s installed in different directories, for example nginx under /usr/sbin on one host and opt/nginx/bin/ on another.