Elastic Kibana APIs
✓ Official Vendor SpecDeveloper ToolsMonitoring ObservabilityapiKey,basic582 EndpointsREST
For Agents
Manage Kibana resources - connectors, alerts, data views, saved objects, Fleet agents, cases, and SLOs - across one or more Kibana spaces.
Use for: I need to create a Kibana connector for sending alerts to Slack, Run an existing Kibana connector with a custom payload, List all alerting rules in the default Kibana space, Provision a new Elastic Agent policy in Fleet
Not supported: Does not handle direct Elasticsearch index search, cluster administration, or metric ingestion - use for managing Kibana resources, Fleet and Elastic Agents, alerting, cases, and observability SLOs only.
Kibana is the Elastic Stack's analytics, search, and observability UI, and these REST APIs expose its administration and operational surface so workflows can run without clicking through the Kibana UI. The 582 endpoints cover alerting and connectors, agent builder and conversations, cases and APM configuration, data views and saved objects, Elastic Agent and Fleet management, security detections and exceptions, observability SLOs, and many more domains. Authentication is either an API key in the Authorization header or HTTP basic auth - and per-space variants of most endpoints support multi-space deployments.
Install Jentic One Beta
Connect the Kibana APIs to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Kibana APIs, 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%2Felastic.co%2Fkibana" | 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%2Felastic.co%2Fkibana" | 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 Kibana APIs.
Create, run, and delete Kibana connectors used by alerting and case automation
Manage alerting rules and observability SLOs across the default and named Kibana spaces
Provision and update Elastic Agents, agent policies, and Fleet enrollment keys
List, build, and converse with Elastic Agent Builder agents through the Kibana API
Create and update data views and saved objects to drive dashboards and visualisations
Open and update cases, attach comments, and link them to APM or security incidents
Query APM agent configuration, source maps, annotations, and APM agent keys
Use Cases
Patterns agents use Kibana APIs for, with concrete tasks.
★ Alerting connector lifecycle automation
An SRE team manages dozens of alerting connectors across environments. The Kibana APIs let them list connector types, create connectors per environment, run a smoke-test execution, and delete obsolete ones - all from CI rather than the UI. Because the same endpoints exist per space, the same automation handles tenanted deployments by iterating /s/{spaceId}/api/actions/connector.
POST /api/actions/connector/{id} with the connector configuration, then POST /api/actions/connector/{id}/_execute with a smoke-test payload to confirm it works.
Fleet and Elastic Agent management at scale
A platform team enrolls Elastic Agents across hundreds of hosts and needs to roll out and roll back agent policies safely. The Kibana Fleet endpoints expose agents, agent policies, enrollment keys, and binary download sources, so the team can script enrollment, policy assignment, and revocation. The /agents and /agent_policies surface gives parity with the Fleet UI.
Create a new agent policy through the agent_policies endpoints, then issue an enrollment key via the enrollment-API-keys endpoints and configure each host to enroll with it.
Observability case management
When a security or APM signal fires, the on-call engineer wants a Kibana case opened automatically with the relevant context attached. The cases endpoints support creating a case, posting comments, and updating its status, so an alerting rule's connector can hand the case off to a human investigator with a full audit trail. Per-space case endpoints keep multi-tenant deployments cleanly separated.
Use the cases endpoints to open a case linked to the firing alert and post the alert payload as a comment on the case.
SLO management for observability
An observability team owns dozens of SLOs across services and spaces. The /s/{spaceId}/api/observability/slos endpoints support listing, deleting, resetting, enabling, and disabling SLOs as services launch and retire. The team scripts SLO bring-up alongside their Terraform pipeline so the SLO definition is part of the service contract.
Call POST /s/{spaceId}/api/observability/slos/{sloId}/_reset to reset the SLO and POST /s/{spaceId}/api/observability/slos/{sloId}/enable to re-enable it after a deployment.
Operations agent for Kibana through Jentic
An ops agent triages Kibana issues - connectors that fail to run, agent policies that need updating, cases to triage. With 582 endpoints, an agent benefits from intent-based discovery rather than reading the full spec. Through Jentic, the agent searches by intent, receives the right Kibana operation, and executes it with the API key Jentic injects at runtime.
Search Jentic for 'run a Kibana connector', load the POST /api/actions/connector/{id}/_execute schema, and execute it with the connector ID and payload supplied by the user.
Key Endpoints
582 endpoints — kibana is the elastic stack's analytics, search, and observability ui, and these rest apis expose its administration and operational surface so workflows can run without clicking through the kibana ui.
METHOD
PATH
DESCRIPTION
GET
/api/actions/connector_types
List connector types
POST
/api/actions/connector/{id}
Create a connector
POST
/api/actions/connector/{id}/_execute
Run a connector
GET
/api/agent_builder/agents
List Agent Builder agents
POST
/api/agent_builder/agents
Create an Agent Builder agent
POST
/s/{spaceId}/api/observability/slos/{sloId}/_reset
Reset an SLO
POST
/s/{spaceId}/api/observability/slos/{sloId}/enable
Enable an SLO
DELETE
/s/{spaceId}/api/observability/slos/{sloId}
Delete an SLO
GET
/api/actions/connector_types
List connector types
POST
/api/actions/connector/{id}
Create a connector
POST
/api/actions/connector/{id}/_execute
Run a connector
GET
/api/agent_builder/agents
List Agent Builder agents
POST
/api/agent_builder/agents
Create an Agent Builder agent
POST
/s/{spaceId}/api/observability/slos/{sloId}/_reset
Reset an SLO
POST
/s/{spaceId}/api/observability/slos/{sloId}/enable
Enable an SLO
DELETE
/s/{spaceId}/api/observability/slos/{sloId}
Delete an SLO
Why Jentic?
What agents get from Jentic-routed access to this vendor.
Setup
Wiring Kibana by hand means pointing at your own Kibana host, handling either API-key or basic auth, and threading the space id through resource paths yourself. Through Jentic you install once, import the Kibana APIs from the API Directory, store the credential once, and your agent calls it.
Permission scoping
Kibana puts the resource id in the URL path (/api/actions/connector/{id}, /s/{spaceId}/api/observability/slos/{sloId}), so a rule can pin your agent to one connector or SLO. You choose the operations it may call, so destructive ones like DELETE on an SLO are not included unless you add them.
Credential isolation
Your Kibana API key or basic credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'run a Kibana connector' or 'reset an observability SLO', and Jentic returns the matching Kibana operation with its input schema so the agent calls the right endpoint without browsing the reference docs.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Kibana APIs through Jentic.
What authentication does the Kibana API use?
Kibana supports two schemes in this spec: an API key passed in the Authorization header (apiKeyAuth) and HTTP basic authentication (basicAuth). Jentic stores either credential encrypted in its vault and injects the Authorization header at execution time so the agent never sees the raw secret.
Can I run a Kibana connector through the API?
Yes. POST /api/actions/connector/{id}/_execute runs a connector with a payload, GET /api/actions/connector_types lists the available connector types, and the connector CRUD endpoints under /api/actions/connector/{id} let you create, update, and delete connectors.
How do I manage Service Level Objectives in observability?
The per-space SLO endpoints under /s/{spaceId}/api/observability/slos/{sloId} support reset, enable, disable, and delete operations, and a sibling /_definitions endpoint returns the SLO definitions for a space.
Does the Kibana API expose Fleet and Elastic Agent management?
Yes. The Fleet domain covers Elastic Agents, agent policies, agentless policies, cloud connectors, enrollment API keys, binary download sources, and Elastic Package Manager (EPM) operations, all via dedicated endpoints in this spec.
What are the rate limits for the Kibana API?
Rate limits are not declared in the spec. Kibana enforces practical limits per deployment based on the underlying Elasticsearch cluster's capacity. Avoid tight polling on the cases, alerts, and saved-objects list endpoints and prefer pagination plus search parameters.
How do I create a Kibana connector through Jentic?
Run pip install jentic, search Jentic for 'create a Kibana connector', load the POST /api/actions/connector/{id} schema, and execute with the connector type and config. Jentic injects the API key, so the agent only handles scoped execution.
Why does this spec mark some internal endpoints as restricted in Kibana 9.0?
The spec includes a NOTE that access to internal Kibana API endpoints will be restricted in Kibana 9.0. Operators planning long-lived integrations should keep to publicly documented endpoints - the FAQ-cited /api/* and /s/{spaceId}/api/* paths above are the supported surface.
Can I limit what my agent is allowed to do with the Kibana API?
Yes. Because you run Jentic One yourself, your own rules decide which Kibana operations and credentials the agent can use. Kibana puts the resource id in the URL path, such as /api/actions/connector/{id} and /s/{spaceId}/api/observability/slos/{sloId}, so you can pin the agent to a single connector or SLO. You also choose which operations are allowed, so destructive calls like DELETE on an SLO stay out of reach unless you add them.
GET STARTED