canonical: https://jentic.com/apis/elastic.co/kibana

# Elastic Kibana APIs

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.

## For AI agents

Manage Kibana resources - connectors, alerts, data views, saved objects, Fleet agents, cases, and SLOs - across one or more Kibana spaces.

## Scope

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.

## Capabilities

- 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

### 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.

Example prompt: 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.

Example prompt: 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.

Example prompt: 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.

Example prompt: 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.

Example prompt: 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

| 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 |

## Key resources

- **Connectors and Actions** — Manage connector types, connectors, and run their actions
- **Alerting** — Create and manage alerting rules and rule executions
- **Agent Builder** — List, create, and converse with Elastic Agent Builder agents
- **Cases** — Open and update cases with comments and linked alerts
- **Data Views and Saved Objects** — Manage Kibana data views and saved objects
- **Fleet** — Manage Elastic Agents, policies, enrollment keys, and binary download sources
- **APM** — Configure APM agents, source maps, annotations, and APM keys
- **Observability SLOs** — Create, reset, enable, and disable Service Level Objectives per space

## Why Jentic

- **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 handling:** 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.
- **Discovery method:** 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

- **Splunk API** — Splunk is a competing observability platform with its own search, alerting, and SOAR APIs.
- **Twilio API** — Twilio sends SMS or voice notifications when Kibana alerting rules fire.
- **Auth0 API** — Auth0 manages identity for users that consume Kibana behind a SaaS-style portal.

## FAQ

### 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.