API Documentation

CtrlOne can be driven programmatically for automation and integration. This guide covers the authentication model and how API access respects roles and tenancy. It focuses on concepts rather than a field-by-field endpoint reference.

Authentication with API tokens

Service accounts authenticate with API tokens rather than an interactive login. A token is presented as a bearer credential on each request. Treat tokens as secrets: store them securely, scope them narrowly, and rotate them if exposed.

curl -H "Authorization: Bearer <YOUR_API_TOKEN>" \
  https://ctrlone.online/api/...

Scoping and roles

API access follows the same authorization model as the console. Tokens are tenant-scoped and carry a role, so automation can only do what that role permits - a read-only integration can't make changes. This keeps programmatic access inside the same guardrails as human operators.

What automation is good for

  • Pulling device and posture data into a SIEM or dashboard.
  • Routing CtrlOne alerts into your existing tooling.
  • Scripting routine operator tasks against your tenant.

Single sign-on

For human operators, CtrlOne supports per-tenant single sign-on via SAML and OIDC. SSO governs interactive console access; API tokens govern service-account automation. Use the right one for each use case.

Frequently asked questions

How does a service account authenticate?

With an API token presented as a bearer credential on each request - not an interactive login.

Can an API token do more than the operator who made it?

No. Tokens are tenant-scoped and role-bound, so automation is held to the same permissions as a human in that role.

Is there single sign-on for operators?

Yes - per-tenant SSO via SAML and OIDC for interactive console access. API tokens are for service-account automation.

Planning an integration?

Reach the CtrlOne team through the contact page to discuss automation, SSO, and enterprise requirements.