Keycloak Admin REST API
Community OpenAPI document · agent-readyIdentity AuthAuthenticationbearer281 Endpoints
Know of an official OpenAPI document? Contribute it →
For Agents
Administer realms, clients, users, groups, roles, identity providers, and authentication flows on a self-hosted Keycloak server through 281 bearer-authenticated endpoints.
Use for: I want to create a new realm in Keycloak, List all clients in a Keycloak realm, Get the user record for a specific Keycloak username, Reset brute-force attack detection for a user
Not supported: Does not handle end-user login flows, OIDC token issuance, or social sign-in UX - use for Keycloak server-side administration of realms, users, clients, and policies only.
This is a Keycloak Admin REST API spec sourced from a community-maintained Keycloak OpenAPI definition (the ccouzens/keycloak-openapi project, capturing Keycloak 10.x). The 281 endpoints cover realm administration, client and client-scope management, users and groups, role mappings, identity providers, authentication flows, and brute-force attack detection. Authentication is bearer-token via Keycloak's own access_token security scheme - the same access tokens issued by Keycloak's OIDC endpoints are reused to call the admin API. The base URL points at a Keycloak instance's /auth/admin/realms/ root, which varies per deployment.
Install Jentic One Beta
Connect the Keycloak Admin REST API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Keycloak Admin REST 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.
1
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%2Fkeycloak.local%2Fkeycloak-local" | sh2
Step 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%2Fkeycloak.local%2Fkeycloak-local" | 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.
Capabilities
What an agent can do with Keycloak Admin REST API.
List, create, update, and delete realms and inspect realm-level admin events
Manage clients, client scopes, and client role mappings inside a realm
Manage users, groups, and the role mappings that control their access
Configure identity providers and authentication flows for a realm
Inspect and clear brute-force attack-detection state for individual users
Read and rotate keys and component configurations for a realm
Use Cases
Patterns agents use Keycloak Admin REST API for, with concrete tasks.
★ Provision Realms and Clients Programmatically
Stand up a new tenant by creating a realm and the clients it needs through the admin API rather than clicking through the Keycloak admin console. The realm and client endpoints support full create, read, update, and delete, so a provisioning script can produce a tenant in one call sequence. Using the API rather than the console makes tenant creation reproducible and reviewable.
POST /{realm} to create the realm, then POST clients under it for each application that needs to authenticate against it
User and Role Mapping Audits
Audit which users and groups hold which roles by walking the realm's user list and pulling role mappings per record. The admin API exposes the full role-mapping graph so an audit job can build a flattened report. Combined with the realm admin-events endpoint, an auditor can also see who granted each mapping and when.
List realm users, then for each user GET their role mappings and join with the admin-events stream to identify recent role changes
Brute-Force Lockout Operations
Build an ops tool that lets support engineers safely clear a brute-force lockout on a single user without touching everyone else in the realm. The /attack-detection/brute-force/users/{userId} endpoint reads and resets the lockout state for one user, while the realm-wide endpoint clears the entire bucket when needed. Both flows are gated on the bearer token, so audit trails capture who took the action.
GET /{realm}/attack-detection/brute-force/users/{userId} to confirm the lockout, then DELETE the same path to reset it
AI Agent Identity Operations
An AI agent that helps an SRE team manage Keycloak uses Jentic to discover the right admin endpoint for each request - clearing a lockout, listing identity providers in a realm, or fetching admin events for a window. Because the surface is large (281 endpoints) and Keycloak's UI does not expose a search-by-intent path, the agent benefits from Jentic's intent-based discovery layer.
Through Jentic, search for 'unlock a keycloak user', load DELETE /{realm}/attack-detection/brute-force/users/{userId}, and execute it for the supplied userId
Key Endpoints
281 endpoints — this is a keycloak admin rest api spec sourced from a community-maintained keycloak openapi definition (the ccouzens/keycloak-openapi project, capturing keycloak 10.
METHOD
PATH
DESCRIPTION
GET
/{realm}
Read a realm by ID
POST
/
Create a new realm
DELETE
/{realm}
Delete a realm
GET
/{realm}/admin-events
Read realm admin events
GET
/{realm}/authentication/authenticator-providers
List authenticator providers
GET
/{realm}/attack-detection/brute-force/users/{userId}
Read brute-force state for a user
DELETE
/{realm}/attack-detection/brute-force/users/{userId}
Clear brute-force lockout for a user
DELETE
/{realm}/attack-detection/brute-force/users
Clear brute-force lockout for the realm
GET
/{realm}
Read a realm by ID
POST
/
Create a new realm
DELETE
/{realm}
Delete a realm
GET
/{realm}/admin-events
Read realm admin events
GET
/{realm}/authentication/authenticator-providers
List authenticator providers
GET
/{realm}/attack-detection/brute-force/users/{userId}
Read brute-force state for a user
DELETE
/{realm}/attack-detection/brute-force/users/{userId}
Clear brute-force lockout for a user
DELETE
/{realm}/attack-detection/brute-force/users
Clear brute-force lockout for the realm
Why Jentic?
What agents get from Jentic-routed access to this vendor.
Setup
Wiring the Keycloak Admin REST API by hand means running the OIDC token exchange, holding the admin bearer, and finding the right route among hundreds of realm, user, and client paths yourself. Through Jentic you install once, import the Keycloak Admin REST API from the API Directory, store the admin credential once, and your agent calls it.
Permission scoping
Keycloak puts the realm in the URL path (/{realm}/...), so a rule can pin your agent to one realm: it can read admin events and attack-detection state there and nothing else. You choose the operations it may call, so destructive ones like deleting the realm or clearing brute-force records are not included unless you add them.
Credential isolation
Your Keycloak admin client_id, client_secret, and admin credentials are stored once, encrypted, by your own Jentic One instance and injected at execution time. Jentic exchanges them at the OIDC token endpoint, so the secrets never enter the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'unlock a Keycloak user' or 'read realm admin events', and Jentic returns the matching admin operation with its schema so the agent calls the right endpoint without walking the full surface.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Keycloak Admin REST API through Jentic.
What authentication does the Keycloak Admin REST API use?
Bearer access tokens issued by Keycloak's own OIDC token endpoint. Send the token in the Authorization header on every admin call. Through Jentic, the client_id, client_secret, and admin credentials live in the encrypted vault and Jentic mints the bearer per call.
Can I create a new realm with the Keycloak Admin REST API?
Yes. POST to the root endpoint with the realm representation in the body. After creation, GET /{realm} returns the realm record so you can confirm it exists, and subsequent calls under /{realm} configure clients, users, and roles inside it.
What are the rate limits for the Keycloak Admin REST API?
Rate limits are deployment-specific. Self-hosted Keycloak does not enforce a fixed numeric limit out of the box - throughput is bounded by the JVM and database behind your instance. If you run admin tooling at scale, batch reads and avoid hot-looping on /{realm}/admin-events.
How do I clear a brute-force lockout for one user via Jentic?
Search Jentic for 'clear keycloak brute force lockout' to find DELETE /{realm}/attack-detection/brute-force/users/{userId}, load its schema, and execute it with the realm and userId. The Jentic flow is pip install jentic, then client.search, client.load, and client.execute.
Does this Keycloak spec cover all admin endpoints?
It exposes 281 admin endpoints - realms, clients, client scopes, users, groups, roles, identity providers, authentication flows, components, and attack detection. The base path is the deployed Keycloak instance's /auth/admin/realms root, so you must configure the host on your Jentic execution context.
Is this spec the official Keycloak OpenAPI definition?
It is sourced from the community ccouzens/keycloak-openapi project, which captures Keycloak 10.x. Keycloak itself has more recently shipped first-party OpenAPI output; for newer Keycloak versions check whether your deployment exposes its own spec at the admin API root.
Can I limit what my agent is allowed to do with the Keycloak Admin REST API?
Yes. Because you run Jentic One yourself, your own rules decide which of the 281 admin operations and which credentials your agent may use. Since Keycloak puts the realm in the URL path, a rule can pin the agent to a single realm, letting it read admin events and brute-force attack-detection state there and nothing else. You choose the exact operations it may call, so destructive ones like deleting a realm or clearing a user's brute-force lockout stay out of reach unless you add them.
GET STARTED