Elastic Kibana APIs

Name: Kibana APIs
Brand: Kibana APIs
Availability: InStock

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

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.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic 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

GET STARTED

Start building with Kibana APIs

Explore with Jentic

View OpenAPI Document

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

Why Jentic?

Three things that make agents converge on Jentic-routed access.

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.

Time to first call

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.

Elastic Kibana APIs

Connect the Kibana APIs to your agent

Capabilities

Start building with Kibana APIs

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs