Elasticsearch-Compatible API¶

IndentiaDB exposes selected Elasticsearch-compatible REST endpoints on port 9200. Supported document, search, mapping, and bulk requests use familiar Elasticsearch shapes. Compatibility does not cover the complete Elasticsearch control plane or guarantee that every client, Kibana, or dashboard workflow works. Test the requests your application uses against the selected IndentiaDB build.

Authentication is enforced whenever IG_ES_ACL_ENFORCE=true or IG_PRODUCTION=true. Use Basic auth (-u root:changeme), an API key header, or a trusted identity proxy — see Identity and Authentication. With both flags off (development only), the API accepts unauthenticated requests. The examples below use Basic auth.

Cluster API¶

GET / — Cluster Info¶

Returns basic cluster information.

curl -u root:changeme http://localhost:9200/

{
  "name": "indentiadb-0",
  "cluster_name": "indentiadb",
  "cluster_uuid": "abc123",
  "version": {
    "number": "8.11.0",
    "build_flavor": "default"
  },
  "tagline": "You Know, for Search"
}

GET /_cluster/health¶

Returns cluster health status.

curl -u root:changeme http://localhost:9200/_cluster/health

{
  "cluster_name": "indentiadb",
  "status": "green",
  "number_of_nodes": 3,
  "number_of_data_nodes": 3,
  "active_primary_shards": 15,
  "active_shards": 30,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 0
}

GET /_cat/indices¶

curl -u root:changeme "http://localhost:9200/_cat/indices?v"

GET /_cat/nodes¶

curl -u root:changeme "http://localhost:9200/_cat/nodes?v"

Index Management¶

Templates, settings, and field capabilities¶

PUT /_index_template/{name} stores templates and applies them to new indices, including automatic index creation. Map facet and access-control fields as keyword before ingestion. allowed_principals is always treated as a keyword, including with dynamic mappings.

GET /{index}/_field_caps reports field capabilities. Index settings can be read and updated through /{index}/_settings. Index expressions can select multiple existing indices; an expression in a mapping or settings update is not an index name to create.

Adding a mapped filter field triggers background presence and filter backfill. An exists query waits for the relevant presence data instead of treating an incomplete backfill as a missing field. Changes to keyword mappings use atomic catalog checks so concurrent updates cannot silently replace each other.

PUT /{index} — Create Index with Mapping¶

Create an index with explicit field mappings:

curl -u root:changeme \
  -X PUT http://localhost:9200/articles \
  -H "Content-Type: application/json" \
  -d '{
    "settings": {
      "number_of_shards": 1,
      "number_of_replicas": 1,
      "refresh_interval": "1s"
    },
    "mappings": {
      "properties": {
        "title": {
          "type": "text",
          "analyzer": "english"
        },
        "title_keyword": {
          "type": "keyword"
        },
        "content": {
          "type": "text",
          "analyzer": "english"
        },
        "author": {
          "type": "keyword"
        },
        "category": {
          "type": "keyword"
        },
        "published_at": {
          "type": "date",
          "format": "strict_date_optional_time"
        },
        "view_count": {
          "type": "integer"
        },
        "embedding": {
          "type": "dense_vector",
          "dims": 1536,
          "index": true,
          "similarity": "cosine"
        }
      }
    }
  }'

Dense Vector Field Configuration¶

The dense_vector type supports three similarity functions:

Full dense vector field example:

"embedding": {
  "type": "dense_vector",
  "dims": 768,
  "index": true,
  "similarity": "cosine",
  "index_options": {
    "type": "hnsw",
    "m": 16,
    "ef_construction": 100
  }
}

The mapping validates dimensions, element type, similarity, and index-option transitions. int8_hnsw stores quantized vectors in the in-memory graph and rescores approximate candidates from source floats. int4_hnsw and bbq_hnsw currently use int8 storage too; they do not provide native 4-bit or binary compression. See Vector search before selecting a format.

GET /{index} — Get Mapping¶

curl -u root:changeme http://localhost:9200/articles

DELETE /{index} — Delete Index¶

curl -u root:changeme -X DELETE http://localhost:9200/articles

Document Operations¶

POST /{index}/_doc — Index with Auto ID¶

curl -u root:changeme \
  -X POST http://localhost:9200/articles/_doc \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Introduction to Graph Databases",
    "content": "Graph databases store data as nodes and edges.",
    "author": "alice",
    "category": "databases",
    "published_at": "2026-03-21T10:00:00Z",
    "view_count": 0
  }'

Response:

{
  "_index": "articles",
  "_id": "abc123xyz",
  "_version": 1,
  "result": "created",
  "_shards": { "total": 2, "successful": 1, "failed": 0 }
}

PUT /{index}/_doc/{id} — Index with Explicit ID¶

curl -u root:changeme \
  -X PUT http://localhost:9200/articles/_doc/article-001 \
  -H "Content-Type: application/json" \
  -d '{
    "title": "SPARQL Query Language",
    "content": "SPARQL is the standard query language for RDF data.",
    "author": "bob",
    "category": "rdf",
    "published_at": "2026-03-15T09:00:00Z"
  }'

GET /{index}/_doc/{id} — Get Document¶

curl -u root:changeme http://localhost:9200/articles/_doc/article-001

Response:

{
  "_index": "articles",
  "_id": "article-001",
  "_version": 1,
  "found": true,
  "_source": {
    "title": "SPARQL Query Language",
    "author": "bob"
  }
}

DELETE /{index}/_doc/{id} — Delete Document¶

curl -u root:changeme \
  -X DELETE http://localhost:9200/articles/_doc/article-001

POST /_mget — Multi-Get¶

Fetch several documents in one request, using either a docs array or an ids array (with POST /{index}/_mget):

curl -u root:changeme \
  -X POST http://localhost:9200/articles/_mget \
  -H "Content-Type: application/json" \
  -d '{ "ids": ["article-001", "article-002"] }'

A single request may fetch at most ES_MGET_MAX_DOCS documents (default 1000). Larger requests are rejected as a whole with the reason _mget requests at most <N> documents, got <M>; split them into smaller batches. When document-level security is enforced, documents the caller may not see are returned as "found": false.

Bulk Operations — POST /_bulk¶

The bulk API processes multiple operations in a single request. Each operation is two lines: an action line and (optionally) a document line.

curl -u root:changeme \
  -X POST http://localhost:9200/_bulk \
  -H "Content-Type: application/x-ndjson" \
  -d '
{"index": {"_index": "articles", "_id": "1"}}
{"title": "Graph Databases", "author": "alice", "category": "databases"}
{"index": {"_index": "articles", "_id": "2"}}
{"title": "Vector Search", "author": "bob", "category": "search"}
{"update": {"_index": "articles", "_id": "1"}}
{"doc": {"view_count": 100}}
{"delete": {"_index": "articles", "_id": "old-doc"}}
'

Supported operation types:

Search API — GET / POST /{index}/_search¶

The _search endpoint supports a rich query DSL. All examples use POST with a JSON body.

1. Match All¶

Return all documents:

curl -u root:changeme \
  -X POST http://localhost:9200/articles/_search \
  -H "Content-Type: application/json" \
  -d '{ "query": { "match_all": {} } }'

2. Match — Full-Text BM25¶

{
  "query": {
    "match": {
      "content": {
        "query": "graph databases traversal",
        "operator": "or"
      }
    }
  }
}

With AND operator (all terms must appear):

{
  "query": {
    "match": {
      "content": {
        "query": "graph database",
        "operator": "and"
      }
    }
  }
}

3. Match Phrase¶

All terms must appear in the specified order:

{
  "query": {
    "match_phrase": {
      "content": "graph database traversal"
    }
  }
}

4. Multi-Match¶

Search across multiple fields simultaneously:

{
  "query": {
    "multi_match": {
      "query": "sparql rdf knowledge graph",
      "fields": ["title^3", "content", "tags"],
      "type": "best_fields"
    }
  }
}

Multi-match types: best_fields, most_fields, cross_fields, phrase, phrase_prefix.

5. Term — Keyword Exact Match¶

{
  "query": {
    "term": {
      "author": { "value": "alice" }
    }
  }
}

6. Terms — Match Any of Multiple Values¶

{
  "query": {
    "terms": {
      "category": ["databases", "rdf", "search"]
    }
  }
}

7. Range¶

{
  "query": {
    "range": {
      "published_at": {
        "gte": "2026-01-01",
        "lte": "2026-12-31"
      }
    }
  }
}

Numeric range:

{
  "query": {
    "range": {
      "view_count": {
        "gte": 100,
        "lt": 10000
      }
    }
  }
}

8. Bool — Compound Queries¶

Combine must, filter, should, and must_not clauses:

{
  "query": {
    "bool": {
      "must": [
        { "match": { "content": "sparql query" } }
      ],
      "filter": [
        { "term": { "category": "rdf" } },
        { "range": { "published_at": { "gte": "2025-01-01" } } }
      ],
      "should": [
        { "term": { "author": "alice" } },
        { "term": { "author": "bob" } }
      ],
      "must_not": [
        { "term": { "status": "draft" } }
      ],
      "minimum_should_match": 1
    }
  }
}

9. Exists¶

Match documents where a field has a non-null value:

{
  "query": {
    "exists": { "field": "embedding" }
  }
}

10. Prefix¶

{
  "query": {
    "prefix": {
      "title": { "value": "graph" }
    }
  }
}

11. Wildcard¶

{
  "query": {
    "wildcard": {
      "title": { "value": "graph*data?" }
    }
  }
}

12. Fuzzy¶

Match terms within a given edit distance:

{
  "query": {
    "fuzzy": {
      "title": {
        "value": "grph databse",
        "fuzziness": "AUTO",
        "max_expansions": 50
      }
    }
  }
}

Fuzzy expansion adds matches next to exact ones rather than replacing them. On the Tantivy text engine (see Enterprise Search), documents that match only through an edit-distance variant are returned after the exact BM25 hits and score below the weakest exact hit.

13. Nested¶

Query fields inside a nested mapping. Set ignore_unmapped: true to make the clause match nothing — instead of failing the search — on indices whose mapping does not declare the path. This lets one query carry an optional nested clause across indices with different mappings:

{
  "query": {
    "bool": {
      "must": [
        { "match": { "content": "graph database" } }
      ],
      "should": [
        {
          "nested": {
            "path": "entities",
            "query": { "match": { "entities.label": "IndentiaDB" } },
            "ignore_unmapped": true
          }
        }
      ]
    }
  }
}

KNN Search — Vector / Nearest Neighbor¶

Top-level knn, kNN queries, and the Elasticsearch 8 _knn_search request shape use the search service. After defaults, k must be at least 1 and num_candidates must lie between k and 10,000. Source filtering, requested fields, and highlighting apply subject to the caller's DLS restrictions.

Vector scores and scripts¶

For cosine, _score is (1 + cosine) / 2. For l2_norm, it is 1 / (1 + squared_distance). Raw distance APIs can use the opposite ordering; do not substitute their output directly for Elasticsearch _score.

script_score supports a bounded Painless subset, including arithmetic, comparisons, conditional expressions, local variables, params, supported doc access, Math functions, and vector similarity functions. It ranks at most max_result_window candidates. Loops, if statements, stored scripts, and other languages are refused with 400. Runtime errors and negative scores fail the request with 400 script_exception.

The intervals query supports positional text constraints. Verify the operators used by your application; support for this query does not imply full Painless or full Elasticsearch Query DSL compatibility.

Use the knn parameter to perform approximate nearest-neighbor search over dense_vector fields.

curl -u root:changeme \
  -X POST http://localhost:9200/articles/_search \
  -H "Content-Type: application/json" \
  -d '{
    "knn": {
      "field": "embedding",
      "query_vector": [0.12, 0.45, 0.78, 0.23, 0.56],
      "k": 10,
      "num_candidates": 100,
      "filter": {
        "term": { "status": "published" }
      }
    },
    "fields": ["title", "author", "published_at"],
    "_source": false
  }'

Hybrid Search — BM25 + KNN¶

Combine full-text BM25 and vector KNN scores in a single request. IndentiaDB merges the result lists using the scorer configured by ES_HYBRID_SCORER (rrf, bayesian, or linear).

curl -u root:changeme \
  -X POST http://localhost:9200/articles/_search \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "bool": {
        "must": [
          { "match": { "content": "graph database knowledge" } }
        ],
        "filter": [
          { "term": { "status": "published" } }
        ]
      }
    },
    "knn": {
      "field": "embedding",
      "query_vector": [0.12, 0.45, 0.78, 0.23],
      "k": 20,
      "num_candidates": 100
    },
    "size": 10,
    "from": 0
  }'

Hybrid Scorer Configuration¶

Set the ES_HYBRID_SCORER environment variable on the server:

Aggregations¶

Terms Aggregation¶

{
  "query": { "match_all": {} },
  "aggs": {
    "categories": {
      "terms": {
        "field": "category",
        "size": 10
      }
    }
  },
  "size": 0
}

Histogram Aggregation¶

{
  "aggs": {
    "view_ranges": {
      "histogram": {
        "field": "view_count",
        "interval": 100
      }
    }
  },
  "size": 0
}

Date Histogram Aggregation¶

{
  "aggs": {
    "articles_over_time": {
      "date_histogram": {
        "field": "published_at",
        "calendar_interval": "month",
        "format": "yyyy-MM"
      }
    }
  },
  "size": 0
}

Metric Aggregations¶

{
  "aggs": {
    "avg_views": { "avg": { "field": "view_count" } },
    "total_views": { "sum": { "field": "view_count" } },
    "max_views": { "max": { "field": "view_count" } },
    "min_views": { "min": { "field": "view_count" } },
    "unique_authors": { "cardinality": { "field": "author" } }
  },
  "size": 0
}

Nested Aggregations¶

{
  "aggs": {
    "by_category": {
      "terms": { "field": "category" },
      "aggs": {
        "avg_views": { "avg": { "field": "view_count" } }
      }
    }
  },
  "size": 0
}

Combine search with SPARQL¶

An _ext block in an Elasticsearch search body is ignored. SPARQL enrichment, knowledge-graph boosting, SPARQL filters, query expansion, and RDF output through _ext are not implemented. Earlier versions of this documentation showed these as working examples; do not use them as an access-control or ranking mechanism.

Enable IG_SPARQL_SEARCH_SERVICE=1 to use the implemented SERVICE <urn:indentia:search> from SPARQL on port 7001:

PREFIX igs: <https://graph.indentia.ai/search#>
SELECT ?doc ?score ?title WHERE {
    SERVICE <urn:indentia:search> {
        [] igs:index "articles" ;
            igs:query "knowledge graph" ;
            igs:k 50 ;
            igs:hit ?doc ;
            igs:score ?score .
    }
    ?doc <http://purl.org/dc/terms/title> ?title .
}
ORDER BY DESC(?score)
LIMIT 10

The service applies the caller's document-level security. It runs once with constant parameters, then joins the top k hits to the graph pattern. Parameters cannot depend on earlier bindings. Graph joins can remove hits, so request more candidates than the final result limit. igs:knnField and igs:vector select vector search; supplying text and a vector combines them with RRF.

Pagination¶

From / Size¶

{
  "query": { "match_all": {} },
  "from": 20,
  "size": 10,
  "sort": [{ "published_at": "desc" }]
}

Search After (Deep Pagination)¶

Use search_after with a sort value from the last result to paginate efficiently without offset overhead:

{
  "query": { "match_all": {} },
  "size": 10,
  "sort": [
    { "published_at": "desc" },
    { "_id": "asc" }
  ],
  "search_after": ["2026-03-01T00:00:00Z", "article-099"]
}

Scroll API¶

For bulk export, scroll retains the matching document IDs and sort keys from the initial search. Each page reads current document values. Updates after opening the scroll appear in later pages, and deleted documents disappear. This differs from Elasticsearch's document snapshot at scroll creation. ES_SCROLL_MAX_HITS bounds retained hits across open scrolls; exceeding the budget returns 429. Scroll is refused for non-administrative callers under document-level security.

# Initialize scroll
curl -u root:changeme \
  "http://localhost:9200/articles/_search?scroll=1m" \
  -H "Content-Type: application/json" \
  -d '{ "size": 100, "query": { "match_all": {} } }'

# Continue scrolling using the scroll_id from the previous response
curl -u root:changeme \
  -X POST "http://localhost:9200/_search/scroll" \
  -H "Content-Type: application/json" \
  -d '{
    "scroll": "1m",
    "scroll_id": "<scroll_id_from_previous_response>"
  }'

Field Collapsing¶

Collapse duplicate results by a field value, returning only the top-ranked document per group:

{
  "query": { "match": { "content": "graph" } },
  "collapse": {
    "field": "author",
    "inner_hits": {
      "name": "other_by_author",
      "size": 3,
      "sort": [{ "published_at": "desc" }]
    }
  }
}

Highlighting¶

Return highlighted snippets showing where query terms matched:

{
  "query": { "match": { "content": "graph database" } },
  "highlight": {
    "fields": {
      "content": {
        "fragment_size": 150,
        "number_of_fragments": 3,
        "pre_tags": ["<mark>"],
        "post_tags": ["</mark>"]
      }
    }
  }
}

Source Filtering¶

Control which fields are included in the _source of each result:

{
  "query": { "match_all": {} },
  "_source": {
    "includes": ["title", "author", "published_at"],
    "excludes": ["embedding", "content"]
  }
}

Disable source entirely (useful when using fields):

{
  "query": { "match_all": {} },
  "_source": false,
  "fields": ["title", "author"]
}

Identity and Authentication¶

Request authentication on port 9200 is enforced whenever IG_ES_ACL_ENFORCE=true or IG_PRODUCTION=true. Apart from GET /health (process liveness), requests without valid credentials are rejected with 401 security_exception.

Trusted Identity Proxy¶

A search front end that has already authenticated the end user can forward that identity instead of real credentials. A request with no Authorization header is authenticated as a proxy principal when it carries X-Indentia-Sid and an X-Indentia-Proxy-Token that matches IG_ES_PROXY_TOKEN (compared in constant time):

curl -X POST http://localhost:9200/articles/_search \
  -H "X-Indentia-Proxy-Token: $IG_ES_PROXY_TOKEN" \
  -H "X-Indentia-Sid: user:alice@example.com,group:finance" \
  -H "Content-Type: application/json" \
  -d '{ "query": { "match": { "content": "budget forecast" } } }'

• Read-only. The proxy principal holds read, view_index_metadata and monitor on indices and monitor on the cluster. It is never a superuser, so document writes are refused with 403.
• Tenant-bound. It is bound to the tenant named by IG_ES_DEFAULT_TENANT and only reaches indices owned by that tenant.
• Fail-closed. Without a configured (non-empty) IG_ES_PROXY_TOKEN, or with a wrong token, the request is not authenticated and gets 401. A request that carries an Authorization header always takes the normal credential path.
• Production. IG_PRODUCTION=true requires both IG_ES_ACL_ENFORCE=true and a non-empty IG_ES_PROXY_TOKEN; the shared secret is what makes the header identity unspoofable. See Production Hardening.

X-Indentia-Sid lists the caller's identities, comma-separated (or as repeated headers): the first value is the user, the rest are groups. Values are Windows-style SIDs (S-1-5-21-…-<rid>) or principal strings such as user:alice@example.com or group:finance. When IG_ES_PROXY_TOKEN is set, X-Indentia-Sid without the matching token is rejected with 401 security_exception. SID headers never grant administrative rights — those come only from an authenticated superuser.

Index Ownership¶

Every index is owned by a tenant, and tenant-bound callers can only use indices their tenant owns. Indices created by the RDF projection (see RDF as Source of Truth) take their owner from the tenant in the document's subject IRI. For writes without a verified tenant this is IG_ES_DEFAULT_TENANT — the tenant the proxy principal is bound to — so proxy reads reach those indices. An index without an owner is claimed by the first write that carries a tenant; an existing owner is never overwritten.

Document-Level Security¶

Set IG_ES_ACL_ENFORCE=true (exactly true or 1) to filter every read on port 9200 by the caller's identity. The server refuses to start with this flag when no ACL is configured. The global switch IG_ACL_ENFORCE=false disables ACL enforcement everywhere, including port 9200, and logs a warning at startup when combined with IG_ES_ACL_ENFORCE=true.

Declaring Visibility¶

Each document lists the principals that may read it in allowed_principals:

curl -u root:changeme \
  -X PUT http://localhost:9200/articles/_doc/budget-2027 \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Budget forecast 2027",
    "content": "Projected spending per department.",
    "allowed_principals": ["group:finance", "user:alice@example.com"]
  }'

• A missing, null or empty allowed_principals is stored as ["acl:public"]: the document is visible to every caller.
• Principals are compared byte-exact (case-sensitive). SIDs are matched in their full S-1-5-21-…-<rid> form.
• On every write the server stamps its own copy of the value into _acl_allowed_principals. The search-time ACL index reads only this server-stamped copy; a _acl_allowed_principals value supplied by a client is overwritten, and _acl_* fields are never returned in _source.
• The caller's principals come only from the verified identity. Under enforcement, an allowed_principals filter in the search request body cannot widen what the caller sees.

How Filtering Works¶

1. Before candidate generation. Visibility (acl:public plus the caller's principals) is applied before scoring, pagination and fusion. With ES_TEXT_ENGINE=tantivy it is compiled into a per-index ACL bitset that is intersected with text, kNN and count candidates, so hidden documents never enter the top-k or the totals. As with Elasticsearch document-level security, BM25 term statistics (IDF) are still computed over the whole index.
2. Inside retriever fusion. Every child of a retriever (standard, knn, and the rrf, linear and bayesian fusion retrievers) and every leg of rank.rrf receives the same server-resolved visibility before fusion, so a hidden document cannot enter any fused result list.
3. Authoritative check per hit. Each returned hit is also checked against the triple-level ACL annotations in the graph (see Triple-Level ACL); hidden hits are dropped and restricted fields are removed from _source. A document must pass both checks, so a disagreement between the document field and the graph can only hide more, never less.
4. Direct reads. GET /{index}/_doc/{id}, HEAD, _source, _mget and _explain use the same decision. A hidden document reads as not found (404 / "found": false), never 403.

Restrictions for Non-Administrative Callers¶

In search responses to non-administrative callers, hits.total is reported as a lower bound ("relation": "gte"), and aggregation results, suggestions, profile output and scroll ids are omitted. /{index}/_count on the Tantivy engine returns the exact number of visible documents.

Cluster Mode¶

In a clustered (HA) deployment every node keeps its own local Elasticsearch document store. A :9200 write that only reached the node receiving it would make the nodes silently diverge behind a load balancer. IndentiaDB therefore guards document writes (_doc, _create, _update, _bulk, _update_by_query, _delete_by_query):

Reads are never blocked by this guard. The refusal names both remedies:

{
  "error": {
    "root_cause": [{ "type": "cluster_block_exception", "reason": "unreplicated document write refused: ..." }],
    "type": "cluster_block_exception",
    "reason": "unreplicated document write refused: ..."
  },
  "status": 503
}

With IG_PRODUCTION=true, a cluster with the Elasticsearch API enabled refuses to boot unless IG_ES_RDF_SOT=true is set, and IG_ES_ALLOW_UNREPLICATED_WRITES is refused in every configuration.

RDF as Source of Truth¶

With IG_ES_RDF_SOT=true, the RDF graph is authoritative and the documents served on port 9200 are a projection of it:

• Document writes are translated into RDF and committed through the same write path as SPARQL UPDATE (Raft in cluster mode). Every node then projects the committed change into its local Elasticsearch store.
• Each document becomes the subject https://id.indentia.ai/sources/<tenant>/es/<index>/<doc_id>. The tenant is the verified caller's tenant, or IG_ES_DEFAULT_TENANT (default default) when request security is not enforced.
• While the projection is not certified against the current graph — for example during startup reconciliation — requests return 503 unavailable_shards_exception with Retry-After: 1. GET /health is exempt.
• Index-management mutations that have no replicated command, such as PUT /{index}, PUT /{index}/_mapping and DELETE /{index}, are refused with 503 cluster_block_exception. An index that does not exist yet is created with a dynamic mapping when the projection writes its first document.

Limits & Error Codes¶

Filter-Index Acceleration¶

bool.filter clauses on non-text fields — term, terms, range and exists — are served from maintained indexes instead of a scan over every document.

The filter fields are a fixed set of common security and facet fields (for example allowed_principals, source_system, document_type, language, author and labels) plus every field the mapping declares as keyword, constant_keyword, boolean, date, a numeric type, ip or version. text fields (full-text index) and dense_vector fields (vector index) are excluded.

Security Hardening¶

Everything a client sends that ends up in the storage query layer is treated as data:

• Field names (including dotted paths), sort keys and object keys from the request body are quoted or escaped. A crafted name can at worst address a field that does not exist; it cannot change the query.
• Document ids — including the values of an ids query — are escaped as string literals.
• term, terms and range values must be scalars; object and array values are rejected with 400.