canonical: https://jentic.com/apis/opensearch.org/opensearch # OpenSearch API OpenSearch is a search and analytics engine, and this API is the full surface for working with a cluster: index documents, run queries, bulk-load data, manage indices and their mappings, and check cluster and node health. An agent can create an index, add or fetch a document, run a search, and read cluster status through the same interface an operator would use. It suits teams building search or log-analytics on self-hosted OpenSearch. Because the deployment is your own, the base URL is your cluster's domain. ## For AI agents Index documents, run searches, bulk-load data, and manage indices and cluster health on a self-hosted OpenSearch deployment. ## Scope Does not provision the cluster hardware itself. Use it to index and search documents, manage indices, bulk-load data, and check cluster health on your self-hosted OpenSearch deployment. ## Capabilities - Create, read, and delete indices - Index, retrieve, and delete documents - Run searches with the query DSL - Bulk-load and update data in one request - Inspect cluster and node health - List indices and their status with the cat endpoints ## Use cases ### Search Queries An agent answers a user's question against indexed data by calling POST /_search with a query, or GET /_search for a simple lookup. This turns a natural request into a structured search over the cluster. Example prompt: Run the query with POST /_search and return the matching documents ### Document Indexing A pipeline agent adds records with PUT /{index}/_doc/{id} for single documents and POST /_bulk for batches, keeping the search index current. Bulk requests cut the round trips when loading many records. Example prompt: Index single records with PUT /{index}/_doc/{id} and batches with POST /_bulk ### Index Management An agent provisions storage by creating an index with PUT /{index} and later removes it with DELETE /{index} when it is no longer needed. This lets a workflow manage its own search space. Example prompt: Create the index with PUT /{index} and delete it with DELETE /{index} when done ### Cluster Health Checks Before a heavy operation, an agent reads GET `/_cluster/health` and lists indices with GET `/_cat/indices` to confirm the cluster is ready. This avoids issuing work against a red or overloaded cluster. Example prompt: Read GET `/_cluster/health` and GET `/_cat/indices` before running heavy work ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | `/_search` | Run a search query | | POST | `/_bulk` | Bulk-load or update documents | | PUT | `/{index}` | Create an index | | GET | `/{index}/_doc/{id}` | Retrieve a document by id | | GET | `/_cluster/health` | Check cluster health | ## Key resources - **Search** — Query documents with the search endpoints - **Documents and Indices** — Index, retrieve, bulk-load, and manage indices - **Cluster** — Cluster and node health and cat endpoints ## Why Jentic - **Setup:** Wiring the OpenSearch API by hand means handling the Authorization header for signed requests, learning a surface of 733 operations across search, documents, indices, and cluster management, and pointing at your own cluster's domain. Through Jentic you install once, import the OpenSearch API from the API Directory, store the credential once, and your agent calls it. - **Permission scoping:** Because you run Jentic One yourself, you decide which OpenSearch operations the agent may call. Allow read-only search and health operations, for example, and leave index creation, bulk writes, and deletes out of the allowed set unless you add them. - **Credential handling:** Your OpenSearch credential is stored once, encrypted, by your own Jentic One instance and injected on the Authorization header at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent, such as 'search an index for matching documents' or 'check cluster health', and Jentic returns the matching OpenSearch operation with its input schema so the agent calls the right endpoint. ## Related APIs - **Meilisearch API** — Meilisearch is a lightweight search engine; OpenSearch is a broader search and analytics platform. - **MongoDB Atlas API** — MongoDB stores primary documents; OpenSearch indexes them for full-text search and analytics. - **Redis API** — Redis serves fast key-value and cache access; OpenSearch handles rich queries over indexed data. ## FAQ ### What can an AI agent do with the OpenSearch API? An agent can create and delete indices, index and retrieve documents, run searches with the query DSL, bulk-load data, and check cluster and node health. It is the full working surface of a self-hosted OpenSearch cluster. ### What authentication does the OpenSearch API use? The specification declares an apiKey scheme that carries credentials in the Authorization header, which is how a signed request such as AWS SigV4 is presented to a managed OpenSearch endpoint. Through Jentic that credential is held by your own instance and set on the Authorization header at execution time. ### What base URL does the OpenSearch API use? OpenSearch is self-hosted, so the base URL is your own cluster's domain rather than a shared host. You point Jentic at your cluster and it calls the same endpoints described here. ### Is there an MCP server for the OpenSearch API? You do not need a separate MCP server to use the OpenSearch API with an agent. Through Jentic One, the self-hosted execution layer, your agent calls the operations directly after you import them from the API Directory. Install Jentic One from github.com/jentic/jentic-one to run it yourself. ### How does my agent discover OpenSearch operations through Jentic? Agents search Jentic by intent, such as 'search an index for matching documents', and Jentic returns the matching operation with its input schema. The agent then calls the right endpoint without reading the full reference. ### Can I limit what my agent is allowed to do with the OpenSearch API? Yes. Because you run Jentic One yourself, you decide which OpenSearch operations the agent may call. You can allow read-only search and health operations, and leave index creation, bulk writes, and deletes out of the allowed set unless you add them, so the agent acts only within the operations you permit.