canonical: https://jentic.com/apis/openobserve.ai/openobserve

# OpenObserve API

Jentic publishes the only available OpenAPI specification for OpenObserve API, keeping it validated and agent-ready. OpenObserve is an open-source observability platform that ingests, stores, and queries logs, metrics, and traces. The API exposes stream management, JSON ingestion, and time-range search across an organization's data, letting agents push telemetry and run queries against existing OpenObserve instances. It is self-hosted, so the base URL is the operator's instance address rather than a vendor-managed endpoint.

## For AI agents

Ingest logs and metrics into OpenObserve, manage streams, and run search queries against an organization's observability data.

## Scope

Does not handle alerting, dashboard rendering, or trace visualisation - use for log and metric ingestion and search only.

## Capabilities

- Ingest JSON log events into a named stream via the _json ingestion endpoint
- Push metrics in JSON form for time-series storage and dashboarding
- List, retrieve, and delete streams under a tenant organization
- Run search queries with time-range filters across stored events
- Poll the status of an asynchronous data-by-time-range job until results are ready
- Cache repeated search results to reduce repeated query cost
- Authenticate per request with HTTP Basic credentials scoped to an organization

## Use cases

### Centralised application log ingestion

Self-hosted services push structured JSON logs into a tenant-scoped stream so engineers can search and correlate events across microservices. OpenObserve handles indexing and time-bucketed storage, and the ingestion endpoint accepts arbitrary JSON event payloads. Setup typically takes a few hours once an OpenObserve instance is running and credentials are issued.

Example prompt: POST a batch of 50 JSON log events to `/api/{organization}/{stream}/_json` with HTTP Basic auth and confirm a 200 response.

### Time-range search for incident investigation

On-call engineers query OpenObserve for events within a specific window to investigate an incident. The data_by_time_range endpoint returns matching events for a stream, and the status endpoint reports when an asynchronous job is complete. This replaces ad-hoc grep over scattered log files with a structured query interface.

Example prompt: Submit a data_by_time_range query for the last 30 minutes against the api-errors stream, then poll `/status/{jobId}` until the job completes.

### Custom metrics ingestion from services

Internal services emit custom metrics directly to OpenObserve via the metrics JSON ingestion endpoint, avoiding the need for a separate StatsD or Prometheus pipeline. Metrics are stored alongside logs and traces under the same organization scope, simplifying operator authentication.

Example prompt: POST a metrics payload with name, value, and timestamp fields to `/api/{organization}/ingest/metrics/_json` and verify acceptance.

### Agent-driven observability through Jentic

AI agents that triage production incidents call OpenObserve via Jentic to fetch relevant logs and metrics for a given service window. Jentic resolves the right ingestion or search operation based on the agent's intent and injects the operator's credentials at execution time so the raw username and password never appear in agent context.

Example prompt: Search Jentic for 'search openobserve logs', load the search operation schema, and execute a query for stream=api-errors over the last hour.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/api/{organization}/{stream}/_json` | Ingest JSON log events into a stream |
| POST | `/api/{organization}/ingest/metrics/_json` | Ingest metrics in JSON form |
| POST | `/api/{organization}/_search` | Run a search query across an organization |
| POST | `/api/{organization}/streams/{streamName}/data_by_time_range` | Submit a time-range search job |
| GET | `/api/{organization}/streams/{streamName}/data_by_time_range/status/{jobId}` | Poll status of a time-range search job |
| GET | `/api/{organization}/streams` | List streams in an organization |

## Key resources

- **Streams** — Create, list, retrieve, and delete log/metric streams under an organization
- **Ingestion** — Push JSON log events and metrics into named streams
- **Search** — Run search queries and time-range data lookups against stored events
- **Jobs** — Track the status of asynchronous data_by_time_range jobs

## Why Jentic

- **Setup:** Wiring the OpenObserve API by hand means pointing at your instance host, sending Basic auth on every request, and threading the organization and stream segments through each ingestion and search call. Through Jentic you install once, import the OpenObserve API from the API Directory, store the credentials once, and your agent calls it.
- **Permission scoping:** You limit the agent to the operations it needs, such as ingesting JSON logs or running a search over a time range. You choose which of the ingestion and search operations it may call, and any you do not grant stay out of reach.
- **Credential handling:** Your OpenObserve Basic-auth username and password are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'send logs to OpenObserve' or 'search OpenObserve by time range', and Jentic returns the matching ingestion or search operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **New Relic API** — Hosted observability platform with logs, metrics, and APM in one product
- **Elastic Kibana API** — Search and analytics over Elasticsearch indexes, including log data
- **Splunk API** — Enterprise log search and SIEM that can sit alongside OpenObserve for security workflows

## FAQ

### Why is there no official OpenAPI spec for OpenObserve API?

OpenObserve does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call OpenObserve API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the OpenObserve API use?

OpenObserve uses HTTP Basic authentication, passing base64-encoded username and password in the Authorization header on every request. Through Jentic, the credentials sit in the encrypted vault and the agent never sees the raw values; Jentic injects the Basic header at execution time.

### Can I ingest both logs and metrics with the OpenObserve API?

Yes. Logs are pushed as JSON events to `/api/{organization}/{stream}/_json`, and metrics use the dedicated `/api/{organization}/ingest/metrics/_json` endpoint. Both are scoped to an organization tenant in the same instance.

### What are the rate limits for the OpenObserve API?

Because OpenObserve is self-hosted, rate limits are governed by the operator's instance configuration rather than a central vendor quota. Plan ingestion volume against the resources of your specific deployment.

### How do I run a time-range search through Jentic?

Search Jentic for 'search openobserve by time range', load the operation that matches `/api/{organization}/streams/{streamName}/data_by_time_range`, and execute it with start/end timestamps. Jentic returns the jobId, and a follow-up call to the status endpoint retrieves the results when ready.

### Why is the base URL in the spec a placeholder?

OpenObserve runs as a self-hosted platform, so the spec uses {instance} as a server variable. Set it to the URL of your own OpenObserve deployment (for example, https://logs.example.com) when configuring the operation through Jentic.

### Can I limit what my agent is allowed to do with the OpenObserve API?

Yes. Because Jentic One is self-hosted, you set the rules that decide which OpenObserve operations your agent may call, so you can grant only what it needs, such as ingesting JSON logs or running a time-range search, while leaving stream deletion or metrics ingestion out of reach. Any operation you do not grant is simply unavailable to the agent, and your Basic-auth credentials are injected at execution time rather than exposed in the agent's context. This lets an operator scope a triage agent to search alone while a separate pipeline handles ingestion.