Know of an official OpenAPI document? Contribute it →
For Agents
List OneLogin users and connected apps and mint OAuth access tokens for SSO administration and identity reporting.
Use for: I need to mint a new OneLogin API access token using my client credentials, List all users in our OneLogin directory for the quarterly access review, List all SaaS apps connected to OneLogin to inventory our SSO footprint, Get a fresh bearer token before calling the OneLogin user list
Not supported: Does not handle SAML or OIDC SSO login flows, MFA enrolment, or end-user role management - use for OneLogin admin token mint, user listing, and app listing only.
Jentic publishes the only available OpenAPI specification for OneLogin API, keeping it validated and agent-ready. OneLogin (now part of One Identity) is an enterprise SSO and identity provider used by mid-market and large organisations to centralise user authentication and SaaS app provisioning. This curated spec covers the API v2 endpoints that anchor most administrative integrations: minting an OAuth access token, listing users, and listing connected applications on the tenant.
Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the OneLogin API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fdevelopers.onelogin.com%2Fonelogin" | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fdevelopers.onelogin.com%2Fonelogin" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
What an agent can do with OneLogin API.
Generate OAuth access tokens for the OneLogin API via POST /auth/token using client_credentials
List directory users on a OneLogin tenant through GET /users for audit, sync, and reporting
List connected SaaS applications via GET /apps to inventory the SSO surface
Target any OneLogin tenant by templating the {subdomain} server variable for multi-tenant tooling
Authenticate downstream calls with the bearer token returned by /auth/token
Anchor identity-and-access workflows in front of provisioning and HRIS pipelines
Patterns agents use OneLogin API for, with concrete tasks.
★ Quarterly user access review export
Compliance teams running SOC2 or ISO27001 access reviews use GET /users to export the OneLogin directory snapshot for review by application owners. The job mints a token via POST /auth/token, pages through users, and writes the result to a Google Sheet or BI tool for sign-off. Pairing with GET /apps gives the full who-can-access-what picture.
POST to /auth/token with client_credentials grant, then call GET /users with the returned bearer token and write the user list to a CSV file.
SSO app inventory and rationalisation
IT teams use GET /apps to inventory every SaaS application connected to OneLogin so they can rationalise the SaaS estate, find shadow apps still wired to SSO, and map app ownership. The output feeds vendor risk reviews and budget conversations. The endpoint returns active and inactive apps so it doubles as a deactivation audit.
After token mint, call GET /apps and produce a markdown table of app name, connector, and active state for the IT review.
Token automation for OneLogin admin scripts
Platform engineering teams running OneLogin admin scripts on schedule (Lambdas, GitHub Actions, internal cron) call POST /auth/token at the start of each run to mint a short-lived bearer token. This avoids storing long-lived credentials in CI secrets and keeps every access scoped to a single run. Tokens default to a one-hour TTL.
Call POST /auth/token with grant_type='client_credentials', store the returned access_token in memory for the run, and use it for subsequent /users and /apps calls.
Agent-driven OneLogin queries via Jentic
AI agents handling IT support or compliance queries (e.g. 'how many users do we have in OneLogin?') can call OneLogin through Jentic without holding the OAuth client_id and client_secret. Jentic stores the credentials in your Jentic One instance, mints a token per call, and exposes high-level intents like 'list OneLogin users' so the agent stays in plain language.
Search Jentic for 'list OneLogin users', load the schema for GET /users, and execute against the configured tenant subdomain - Jentic handles the token mint.
3 endpoints — jentic publishes the only available openapi specification for onelogin api, keeping it validated and agent-ready.
METHOD
PATH
DESCRIPTION
/auth/token
Generate an OAuth access token
/users
List directory users
/apps
List connected applications
/auth/token
Generate an OAuth access token
/users
List directory users
/apps
List connected applications
What agents get from Jentic-routed access to this vendor.
Setup
Wiring the OneLogin API by hand means minting a fresh bearer token from your client_id and client_secret, filling in your account subdomain host, and refreshing that token yourself. Through Jentic you install once, import the OneLogin API from the API Directory, store the client credentials once, and your agent calls it.
Permission scoping
You choose which OneLogin operations the agent may call, so you can limit it to the ones it needs, such as listing users and listing connected apps, and leave the token mint out of the agent's own reach unless you add it. That keeps the agent to admin reads without touching login or MFA flows.
Credential isolation
Your OneLogin client_id and client_secret are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'list OneLogin users' or 'list connected apps', and Jentic returns the matching OneLogin operation with its input schema so the agent calls the right endpoint without browsing the reference docs.
Alternatives and complements available in the Jentic catalogue.
Specific to using OneLogin API through Jentic.
Why is there no official OpenAPI spec for OneLogin API?
OneLogin publishes API documentation but not a single canonical OpenAPI specification covering the v2 admin surface. Jentic generates and maintains this spec so that AI agents and developers can call OneLogin API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.
What authentication does the OneLogin API use?
OneLogin uses HTTP bearer authentication. Mint a token by calling POST /auth/token with grant_type=client_credentials and the client_id and client_secret as basic auth, then pass the returned access_token as 'Authorization: Bearer <token>' on subsequent calls. Jentic handles the mint and refresh transparently.
Can I list all my OneLogin users with this API?
Yes. GET /users returns the directory of users on your tenant. The API is paginated; iterate through the cursor in the response to retrieve every record. Use this for access reviews and HRIS sync.
What are the rate limits for the OneLogin API?
OneLogin enforces a per-tenant rate limit that is not declared in the OpenAPI spec. Standard tenants typically allow several thousand requests per hour with stricter limits on /auth/token. Build with retry-on-429 and confirm the live limit in the OneLogin admin console.
How do I list OneLogin users through Jentic?
Run pip install jentic, then with the async client search for 'list OneLogin users', load the schema for GET /users, and execute. Jentic mints the bearer token automatically using the stored client credentials.
Does this OneLogin spec cover SSO login flows?
No. The spec covers the admin v2 surface (token mint, users, apps). SAML and OIDC SSO login flows are exposed through separate OneLogin endpoints not included in this spec.
Can I limit what my agent is allowed to do with the OneLogin API?
Yes. Because Jentic One is self-hosted, you decide which OneLogin operations your agent may call and your own rules govern the credentials it can use. You can allow it just the admin reads it needs, such as listing directory users via GET /users and listing connected apps via GET /apps, while leaving the OAuth token mint on POST /auth/token out of the agent's reach unless you choose to grant it. That keeps the agent scoped to identity reporting without touching login or MFA flows.
GET STARTED