Use the Okta CLI from KosmoKrator to call Okta tools headlessly, return JSON, inspect schemas, and automate workflows from coding agents, scripts, and CI.
Okta can be configured headlessly with `kosmokrator integrations:configure okta`.
# Install KosmoKrator first if it is not available on PATH.curl -fsSL https://raw.githubusercontent.com/OpenCompanyApp/kosmokrator/main/install.sh | bash# Configure and verify this integration.kosmokrator integrations:configure okta --set api_token="$OKTA_API_TOKEN" --set domain="$OKTA_DOMAIN" --enable --read allow --write ask --jsonkosmokrator integrations:doctor okta --jsonkosmokrator integrations:status --json
Credentials
Authentication type: API tokenapi_token. Configure credentials once, then use the same stored profile from
scripts, coding CLIs, Lua code mode, and the MCP gateway.
Key
Env var
Type
Required
Label
api_token
OKTA_API_TOKEN
Secret secret
yes
API Token
domain
OKTA_DOMAIN
Text string
yes
Okta Domain
Call Okta Headlessly
Use the generic call form when another coding CLI or script needs a stable universal interface.
Every function below can be called headlessly. The generic form is stable across all integrations;
the provider shortcut is shorter but specific to Okta.
okta.okta_list_users
Read read
List users in the Okta organization. Returns user profiles with IDs, names, emails, and status. Supports search filtering by name or email.
Get details for a specific Okta user by ID or login email. Returns the full user profile including status, group memberships, and assigned applications.
Get the profile of the currently authenticated Okta API token owner. Useful for verifying the integration connection and identifying which service account is in use.
Create a new user in Okta. Requires a profile with at least firstName, lastName, email, and login. Optionally provide credentials (password) and control activation.
Deactivate an Okta user. The user will be unable to sign in but their data is retained. This action can be reversed by reactivating the user in the Okta admin console.
Maximum number of users to return (1–200, default: 200).
q
string
no
Search query to filter users by first name, last name, or email.
okta.okta_get_user
Get details for a specific Okta user by ID or login email. Returns the full user profile including status, group memberships, and assigned applications.
Get the profile of the currently authenticated Okta API token owner. Useful for verifying the integration connection and identifying which service account is in use.
Create a new user in Okta. Requires a profile with at least firstName, lastName, email, and login. Optionally provide credentials (password) and control activation.
Updated profile fields. Only include fields you want to change (e.g., firstName, lastName, email, title, department, etc.).
credentials
object
no
Updated credentials (e.g., new password). Optional.
okta.okta_deactivate_user
Deactivate an Okta user. The user will be unable to sign in but their data is retained. This action can be reversed by reactivating the user in the Okta admin console.
Headless calls still follow the integration read/write permission policy. Configure read/write defaults
with integrations:configure. Add --force only for trusted automation that should bypass that policy.