OriginChainDB
Elasticsearch clients

Connect an Elasticsearch client

Use a supported Elasticsearch 7.x client to send document, search and aggregation requests to OriginChainDB. Start with one connection check and one sample document before moving an application.

This compatibility API requires a supported dedicated deployment. It is separate from the normal application Connect flow. Confirm its complete endpoint and credential requirements in current support.

Connect an Elasticsearch-compatible clientThe dedicated endpoint supports a documented subset, not every Elasticsearch operation.
  1. Copy the search endpointUse the separate endpoint supplied for your dedicated instance.
  2. Configure a supported clientUse the documented Elasticsearch 7.x connection settings.
  3. Index one test documentChoose an explicit mapping and a known document ID.
  4. Search and verify itConfirm the returned ID and fields match what you wrote.

What you can connect.

Use a client that supports the Elasticsearch 7.x REST API, and test the operations your application needs against the supported subset. The endpoint reports version 7.14.2. This is not a claim of compatibility with every client, dashboard, or query.

Connection details.

Point the client at your endpoint and authenticate with an API key from the console. info() is the handshake — it is what the client uses to confirm it is talking to Elasticsearch.

const { Client } = require('@elastic/elasticsearch')

const es = new Client({
  node: 'https://<your-es-endpoint>',   // your instance URL + /v1/tenants/<tenant>/es
  auth: { username: 'originchaindb', password: process.env.OC_API_KEY }
})

await es.info()   // reports version 7.14.2

Insert data.

Index a single document by _id. It is searchable the instant the call returns — there is no refresh interval to wait on.

await es.index({
    index: 'shop.products',
    id: 'sku-8842',
    body: { name: 'Carbon Marathon', brand: 'Aero', price: 149 }
})

Load many at once with _bulk (newline-delimited actions). This is the fast path for backfills and ingest.

await es.bulk({
    body: [
        { index: { _index: 'shop.products', _id: 'sku-1207' } },
        { name: 'Trail 24', brand: 'Aero', price: 89 },
        { index: { _index: 'shop.products', _id: 'sku-3355' } },
        { name: 'City Runner', brand: 'Metro', price: 72 }
    ]
})

Or straight over HTTP — the same NDJSON body a stock Elasticsearch cluster takes:

POST /_bulk
{"index":{"_index":"shop.products","_id":"sku-1207"}}
{"name":"Trail 24","brand":"Aero","price":89}

_update is a partial merge — the fields you send are updated and every other field is preserved.

await es.update({
    index: 'shop.products', id: 'sku-8842',
    body: {
        doc: { price: 139 } // name, brand, ... untouched
    }
})

Search and aggregate.

The Query DSL you already write — bool, match, term, filters — with aggregations in the same request.

await es.search({
    index: 'shop.products',
    body: {
        query: { bool: {
                must: [{ match: { name: 'marathon' } }],
                filter: [{ term: { brand: 'Aero' } }]
            } },
        aggs: { by_brand: { terms: { field: 'brand' } } }
    }
})

Also supported: _count, _msearch, _mget, search_after deep paging, collapse, _delete_by_query and _update_by_query (both honor max_docs), and _reindex into a fresh index. Read a document straight back with GET or HEAD /:index/_doc/:id, or /:index/_source/:id for the bare document; ask what a field looks like with _field_caps; and guard a bulk write with if_seq_no — a stale precondition comes back as a per-item 409 and every other item in the batch still lands.

Use the identity and access rules intended for the application. Test both permitted and denied queries, including searches over sensitive fields. Keep credentials on the server and review authentication before exposing a search endpoint to users.

Limits, stated plainly.

The API implements a documented subset of the Elasticsearch surface. Unsupported request bodies can return an explicit error, but unknown URL parameters are currently ignored. A successful response does not confirm that every requested option was applied.

  • Aggregations: terms, metrics, range, histogram, date_histogram, percentiles, top_hits, sub-aggregations and pipeline aggs are in, and so is filters — named buckets, each its own query, with sub-aggregations over exactly that bucket. Send filters in its own request: it is answered with one search per filter. extended_stats is also supported. composite and nested are not answered yet, and missing on a metric aggregation is refused rather than filled in with a value you did not choose.
  • Suggesters: the term suggester corrects a word against what is actually indexed in a field, with suggest_mode honored. Options carry the corrected text and a score, and no document frequency — that number is not available to this API, and we would rather omit a field than report one we cannot stand behind. The phrase and completion suggesters are refused by name.
  • Scoring: function_score and per-field boosts are in; script_score and rescore are refused.
  • Deep paging: search_after for sorted pagination. Scroll and Point-in-Time (PIT) are also supported; inspect /v1/capabilities for deployment limits.
  • Cluster management: Legacy and composable index templates are supported. ILM and snapshot administration are not supported over this API. Vector / kNN search lives on a dedicated surface.
  • Version: the cluster reports 7.14.2; pin clients to the 7.x line.

Feature coverage is a separate question from scale — see Full-text search for how the index is built and what a single node holds.

Elasticsearch is a trademark of Elasticsearch B.V., registered in the U.S. and in other countries. OriginChainDB is not affiliated with, endorsed by, or sponsored by Elasticsearch B.V. OriginChainDB implements a compatible HTTP API so that existing Elasticsearch clients can talk to it; it does not distribute Elasticsearch software.

© 2026 Silicoyn Technologies Pvt Ltd

On this page