For Agents
Ingest logs and metrics into OpenObserve, manage streams, and run search queries against an organization's observability data.
Use for: I need to send a batch of application logs to OpenObserve, Search OpenObserve logs for errors in the last hour, List all streams in my OpenObserve organization, Retrieve the status of a long-running search job
Not supported: Does not handle alerting, dashboard rendering, or trace visualisation — use for log and metric ingestion and search only.
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.
Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the OpenObserve 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.
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 | shStep 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 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.
What an agent can do with OpenObserve API.
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
Patterns agents use OpenObserve API for, with concrete tasks.
★ 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.
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.
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.
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.
Search Jentic for 'search openobserve logs', load the search operation schema, and execute a query for stream=api-errors over the last hour.
9 endpoints — jentic publishes the only available openapi specification for openobserve api, keeping it validated and agent-ready.
METHOD
PATH
DESCRIPTION
/api/{organization}/{stream}/_json
Ingest JSON log events into a stream
/api/{organization}/ingest/metrics/_json
Ingest metrics in JSON form
/api/{organization}/_search
Run a search query across an organization
/api/{organization}/streams/{streamName}/data_by_time_range
Submit a time-range search job
/api/{organization}/streams/{streamName}/data_by_time_range/status/{jobId}
Poll status of a time-range search job
/api/{organization}/streams
List streams in an organization
/api/{organization}/{stream}/_json
Ingest JSON log events into a stream
/api/{organization}/ingest/metrics/_json
Ingest metrics in JSON form
/api/{organization}/_search
Run a search query across an organization
/api/{organization}/streams/{streamName}/data_by_time_range
Submit a time-range search job
/api/{organization}/streams/{streamName}/data_by_time_range/status/{jobId}
Poll status of a time-range search job
/api/{organization}/streams
List streams in an organization
Three things that make agents converge on Jentic-routed access.
Credential isolation
OpenObserve Basic-auth credentials are stored encrypted in the Jentic vault. Agents receive scoped execution access — the username and password never enter the agent's context window.
Intent-based discovery
Agents search by intent (e.g., '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 does not need to read the OpenObserve docs.
Time to first call
Direct OpenObserve integration: half a day to set up auth, choose endpoints, and handle the async search status loop. Through Jentic: under 30 minutes — search, load schema, execute.
Alternatives and complements available in the Jentic catalogue.
Specific to using OpenObserve API through Jentic.
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 at https://app.jentic.com/sign-up.
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.
GET STARTED