OriginChainDB

HTTP API reference.

Use these HTTP requests as references for individual engine operations. Choose the section for your task, prepare the named schema or index and inspect the status and response before continuing.

These examples use explicit tenant-scoped routes and legacy host variables. For a new application, use the complete OC_URL and supported OC_TOKEN supplied by Connect; do not construct the URL from an instance name. Endpoint-specific fields still come from the API reference.

Adapt a recipe to its interfaceThese reference recipes use explicit engine settings; do not shorten the complete address from Connect.
  1. Find the operationChoose the recipe for the row, query or index task.
  2. Check its connection contractUse the endpoint variables and credentials that interface requires.
  3. Send the small requestPrepare the named table or index first.
  4. Read status and responseVerify the result before chaining another operation.

Check the engine you are connected to

Read GET /v1/capabilities on your instance's HTTPS endpoint. It distinguishes supported features, scoped previews and roadmap entries, and includes deployment-dependent notes. A feature in source code is not proof it is enabled on your instance. Use Connect for listener status and the release notes for rollout history.

Idempotency and uncertain writes

Schema registration, supporting row-write and batch routes, and selected Elasticsearch mutations implement idempotency handling. This is not a global guarantee for every POST, SQL statement, vector request or transaction commit. Check the specific endpoint before building a retry loop.

Keep the same key and body for one logical operation. A new application-level SDK call may generate a new key. Replay protection is bounded by the server's retention and scope; it is not a permanent exactly-once guarantee. If a commit response is lost, reconcile its outcome before repeating a non-idempotent mutation.

Schemas

TOML manifests describe a table - its primary key, columns, indexes, and relations. The engine indexes everything off the manifest, so registering one is the prerequisite to any row write.

POST /v1/tenants/:tenant/schemas - Register a new TOML manifest; existing schema IDs return 409. Body is the raw TOML; Content-Type: text/plain.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/schemas" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: text/plain" \
  --data-binary @orders.toml

200 OK

{ "id": "trading.orders", "version": 1 }

GET /v1/tenants/:tenant/schemas - List every schema id registered for the tenant.

curl "$OC_BASE_URL/v1/tenants/$OC_TENANT/schemas" \
  -H "Authorization: Bearer $OC_TOKEN"

200 OK

["trading.orders", "trading.trades", "trading.users"]

GET /v1/tenants/:tenant/schemas/:id - Fetch the raw TOML for a schema id. Response is text/plain, not JSON.

curl "$OC_BASE_URL/v1/tenants/$OC_TENANT/schemas/trading.orders" \
  -H "Authorization: Bearer $OC_TOKEN"
# text/plain
namespace   = "trading"
table       = "orders"
primary_key = ["order_id"]
...

Rows (typed CRUD)

Insert, batch, and read against a registered schema. Single-row writes are atomic; the batch endpoint accepts a JSON array (atomic in one commit) or NDJSON via `application/x-ndjson` (streamed in flushable chunks).

POST /v1/tenants/:tenant/rows/:schema - Upsert a single row. `?expect=insert` requests insert-only behavior: a duplicate primary key conflicts instead of overwriting the row. Use the supported idempotency header consistently for the same row operation; reconcile an uncertain write before changing its key or body.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/rows/trading.orders" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "order_id": "o-0001",
    "symbol":   "AAPL",
    "qty":      100
  }'
{ "ok": true, "lsn": { "segment": 4, "offset": 8421007 } }

POST /v1/tenants/:tenant/rows/:schema/_batch - Atomic batch (one durable commit). JSON body: a row array. NDJSON body (Content-Type: application/x-ndjson): streamed; flushes every `?chunk=N` rows (default 1000, max 10000). 8 MiB body cap is disabled on this route.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/rows/trading.orders/_batch" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: bulk-2026-05-01-batch-1" \
  -d '[
    { "order_id": "o-1", "symbol": "AAPL", "qty": 100 },
    { "order_id": "o-2", "symbol": "MSFT", "qty": 250 }
  ]'

200 OK

{ "inserted": 2, "lsn": { "segment": 4, "offset": 8425112 } }

GET /v1/tenants/:tenant/rows/:schema/:pk - Read a row by its single-column primary key. Composite PKs must use POST /query with a ColumnScan plan.

curl "$OC_BASE_URL/v1/tenants/$OC_TENANT/rows/trading.orders/o-0001" \
  -H "Authorization: Bearer $OC_TOKEN"
{
  "order_id": "o-0001",
  "symbol":   "AAPL",
  "qty":      100,
  "_oc_row_version": 1
}

Query - Plan tree (JSON)

The engine's native execution surface. POST a JSON Plan tree and get rows back. `?explain=true` returns the executed plan annotated with stats (EXPLAIN ANALYZE). Cancel an in-flight plan with the ULID handed back in `X-OC-Query-Id`.

POST /v1/tenants/:tenant/query - Execute a Plan tree. Bare response is `Vec<row>`; with `?explain=true` it's `{rows, explain}`.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/query" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "Limit": {
      "n": 10,
      "child": {
        "Filter": {
          "predicate": { "Eq": ["status", "pending"] },
          "child":     { "Scan": { "schema": "trading.orders" } }
        }
      }
    }
  }'
[
  { "order_id": "o-0001", "symbol": "AAPL", "status": "pending", ... },
  ...
]

POST /v1/tenants/:tenant/query?explain=true - EXPLAIN ANALYZE: executes the plan and returns it annotated with per-node row counts and µs timings.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/query?explain=true" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "Scan": { "schema": "trading.orders" } }'

200 OK

{
  "rows": [ ... ],
  "explain": {
    "op":       "Scan",
    "schema":   "trading.orders",
    "rows_out": 412,
    "elapsed_us": 1340,
    "children": []
  }
}

POST /v1/queries/:id/cancel - Flip the cancellation token for an in-flight plan. The id is the ULID returned in `X-OC-Query-Id` on the original request.

curl -X POST "$OC_BASE_URL/v1/queries/01HW7G5...JZ/cancel" \
  -H "Authorization: Bearer $OC_TOKEN"

200 OK (always; cancelled=false if already finished)

{ "cancelled": true }

GET /v1/tenants/:tenant/watch - Server-Sent Events stream. The connection holds open; the server pushes one event per change burst against the subscribed schemas. Ctrl-C / client close ends the subscription.

curl -N "$OC_BASE_URL/v1/tenants/$OC_TENANT/watch?schemas=trading.orders" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Accept: text/event-stream"

200 OK (text/event-stream)

event: snapshot
data: { "rows": [ ... ] }

event: snapshot
data: { "rows": [ ... ] }

SQL

SELECT, INSERT, UPDATE and DELETE execute on the SQL endpoint. Do not re-issue a successful SQL mutation against the row API. The response kind and fields depend on the statement; see the SQL reference and transaction guide for commit boundaries.

POST /v1/tenants/:tenant/sql - Send a JSON object with a sql string and optional positional params array. SELECT returns rows; mutations return a statement-specific receipt. Writes execute: do not replay the returned rows.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/sql" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "sql": "SELECT order_id, symbol, qty FROM trading.orders WHERE status = '"'"'pending'"'"' LIMIT 10" }'
// Illustrative response shapes. INSERT and DELETE execute.
{ "kind": "select", "rows": [{"order_id":"o-1","symbol":"AAPL","qty":100}] }
// INSERT receipt: inspect the returned kind/rows; do not insert them again.
{ "kind": "insert", "schema": "trading.orders", "rows": [{"order_id":"o-1","symbol":"AAPL","qty":100}] }
// DELETE receipt outside a transaction, for one matching row:
{ "kind": "delete", "schema": "trading.orders", "pk": "o-1", "rows_affected": 1 }

Vector search

Store an embedding, then compare a query embedding using the same dimensions and metric. HNSW search is approximate; high_recall searches more candidates than fast. Measure recall and latency on your own data. Metadata filters use values saved with the vector.

The following pair uses a complete three-dimensional vector in a new embeddings collection. Replace it with embeddings from your chosen model for real similarity search; do not mix different dimensions or models in the collection.

POST /v1/tenants/:tenant/vector/:table/put - Upsert one vector. Optional `metadata` object is indexed for filtered topk.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/vector/embeddings/put" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "id":        "doc-001",
    "embedding": [1.0, 0.0, 0.0],
    "dim":       3,
    "metric":    "cosine",
    "metadata":  { "lang": "en", "tier": "premium" }
  }'

201 Created

// 201 Created (no body)

POST /v1/tenants/:tenant/vector/:table/topk - k-nearest neighbour search. `mode=high_recall` (default) or `mode=fast`. These select a recall/latency profile; they are not index-family names. Non-empty `filter` triggers HNSW + post-filter on metadata equality.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/vector/embeddings/topk" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "query":  [0.9, 0.1, 0.0],
    "k":      10,
    "dim":    3,
    "metric": "cosine",
    "mode":   "high_recall",
    "filter": { "lang": "en" }
  }'

200 OK

[
  { "id": "doc-001", "score": 0.9939 }
]

With only the vector inserted above, the result contains that ID. The displayed cosine score is rounded.

Full-text search

Per-field, per-tenant inverted index. Tokenizer is UAX #29 (Latin / Cyrillic / CJK / Arabic / Hindi). Modes: `boolean` (AND), `bm25` (ranked, default Lucene k1=1.2 b=0.75), and `phrase` (exact contiguous tokens).

POST /v1/tenants/:tenant/fts/:table/:field - Index a document under (table, field). Re-indexing the same `doc_id` cleans stale postings.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/fts/articles/body" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "doc_id": "art-001", "text": "OriginChainDB ships managed AI-native storage." }'

201 Created

// 201 Created (no body)

GET /v1/tenants/:tenant/fts/:table/:field?q=&mode=&k= - Search. `mode=boolean|bm25|phrase` (default boolean). `k` caps results in `mode=bm25` (default 10).

curl "$OC_BASE_URL/v1/tenants/$OC_TENANT/fts/articles/body?q=substrate%20managed&mode=boolean" \
  -H "Authorization: Bearer $OC_TOKEN"

200 OK

// boolean / phrase
["art-001", "art-007"]

// bm25
[ { "doc_id": "art-001", "score": 7.42 }, { "doc_id": "art-007", "score": 5.18 } ]

Elasticsearch API

Use a supported Elasticsearch 7.x client with the explicit compatibility endpoint. Test its requests against the documented subset, including per-item bulk results and version conditions. Other query models have separate interfaces. Start with Connect an Elasticsearch client.

PUT/v1/tenants/:tenant/es/:index- Create an index and its mapping. Field types are the Elasticsearch types your client already sends.

curl -X PUT "$OC_BASE_URL/v1/tenants/$OC_TENANT/es/shop.products" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  --data-binary @mapping.json

200 OK

{ "acknowledged": true, "shards_acknowledged": true, "index": "shop.products" }

PUT/v1/tenants/:tenant/es/:index/_doc/:id- Index (create or replace) a document by _id. Searchable the instant the call returns - no refresh to wait on.

curl -X PUT "$OC_BASE_URL/v1/tenants/$OC_TENANT/es/shop.products/_doc/sku-8842" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  --data-binary @doc.json

201 Created

{ "_index": "shop.products", "_id": "sku-8842", "result": "created", "_version": 1 }

POST/v1/tenants/:tenant/es/_bulk- Bulk index / update / delete. NDJSON: an action line, then (for index/update) a source line. The fast path for ingest.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/es/_bulk" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/x-ndjson" \
  --data-binary @ops.ndjson

200 OK

{
  "errors": false,
  "items": [
    { "index":  { "_id": "sku-1207", "status": 201 } },
    { "update": { "_id": "sku-8842", "status": 200 } }
  ]
}

POST/v1/tenants/:tenant/es/:index/_update/:id- Partial update. The fields in doc are merged in; every other field on the document is preserved.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/es/shop.products/_update/sku-8842" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  --data-binary @patch.json

200 OK

{ "_index": "shop.products", "_id": "sku-8842", "result": "updated", "_version": 2 }

POST/v1/tenants/:tenant/es/:index/_search- Search with the Query DSL, with aggregations in the same request. RLS and column masking apply to the query itself.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/es/shop.products/_search" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  --data-binary @query.json

200 OK

{
  "took": 6,
  "hits": {
    "total": { "value": 1, "relation": "eq" },
    "hits": [ { "_id": "sku-8842", "_score": 7.41,
              "_source": { "name": "Carbon Marathon", "brand": "Aero", "price": 149 } } ]
  },
  "aggregations": { "by_brand": { "buckets": [ { "key": "Aero", "doc_count": 1 } ] } }
}

POST/v1/tenants/:tenant/es/:index/_count- Count the documents matching a query.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/es/shop.products/_count" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  --data-binary @query.json

200 OK

{ "count": 1 }

GET/v1/tenants/:tenant/es/:index/_doc/:id- Read one document by id. HEAD on the same path answers existence only, and /_source/:id returns the document with no envelope.

curl "$OC_BASE_URL/v1/tenants/$OC_TENANT/es/shop.products/_doc/sku-8842" \
  -H "Authorization: Bearer $OC_API_KEY"

# bare document, one field
curl "$OC_BASE_URL/v1/tenants/$OC_TENANT/es/shop.products/_source/sku-8842?_source_includes=price" \
  -H "Authorization: Bearer $OC_API_KEY"
{
  "_index": "shop.products", "_id": "sku-8842",
  "_version": 2, "found": true,
  "_source": { "name": "Carbon Marathon", "brand": "Aero", "price": 139 }
}

GET/v1/tenants/:tenant/es/:index/_field_caps- What each field is, read from the stored mapping. This is the call dashboards make on connect.

curl "$OC_BASE_URL/v1/tenants/$OC_TENANT/es/shop.products/_field_caps?fields=*" \
  -H "Authorization: Bearer $OC_API_KEY"
{
  "indices": ["shop.products"],
  "fields": {
    "name":  { "text":    { "type": "text", "searchable": true, "aggregatable": false } },
    "brand": { "keyword": { "type": "keyword", "searchable": true, "aggregatable": true } },
    "price": { "long":    { "type": "long", "searchable": true, "aggregatable": true } }
  }
}

POST/v1/tenants/:tenant/es/:index/_delete_by_query- Delete matching documents. Honors max_docs; an unbounded whole-table delete is refused rather than run.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/es/shop.products/_delete_by_query" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  --data-binary @query.json

200 OK

{ "total": 3, "deleted": 3, "failures": [] }

Graph traversal

Reads relations declared on a manifest. PKs are passed as path-encoded strings (single-column, string-typed).

GET /v1/tenants/:tenant/graph/:schema/neighbors?rel=&pk= - Forward one-hop. Returns the destination PKs along `rel` from `pk`.

curl "$OC_BASE_URL/v1/tenants/$OC_TENANT/graph/social.users/neighbors?rel=follows&pk=alice" \
  -H "Authorization: Bearer $OC_TOKEN"

200 OK

["bob", "carol", "dave"]

GET /v1/tenants/:tenant/graph/:schema/reverse?rel=&pk= - Inbound one-hop: who points AT `pk` along `rel`. Use the registered relation and destination key; see the graph reference for relation direction and supported key shapes.

curl "$OC_BASE_URL/v1/tenants/$OC_TENANT/graph/social.users/reverse?rel=follows&pk=bob" \
  -H "Authorization: Bearer $OC_TOKEN"

200 OK

["alice", "frank"]

GET /v1/tenants/:tenant/graph/:schema/bfs?rel=&pk=&max_depth= - Breadth-first search up to `max_depth` (default 3). Returns reachable nodes with depth.

curl "$OC_BASE_URL/v1/tenants/$OC_TENANT/graph/social.users/bfs?rel=follows&pk=alice&max_depth=2" \
  -H "Authorization: Bearer $OC_TOKEN"

200 OK

[
  { "pk": "bob",   "depth": 1 },
  { "pk": "carol", "depth": 1 },
  { "pk": "ed",    "depth": 2 }
]

GET /v1/tenants/:tenant/graph/:schema/path?rel=&src=&dst=&max_depth= - Reachability check: is there an `rel`-path from `src` to `dst` within `max_depth` hops?

curl "$OC_BASE_URL/v1/tenants/$OC_TENANT/graph/social.users/path?rel=follows&src=alice&dst=ed&max_depth=3" \
  -H "Authorization: Bearer $OC_TOKEN"

200 OK

{ "reachable": true }

GET /v1/tenants/:tenant/graph/:schema/dijkstra?rel=&src=&dst=&weights_json= - Weighted shortest-path. `weights_json` is a JSON object mapping `"<from>|<to>"` -> f64. A manifest weight-column variant is available - contact support.

curl --get "$OC_BASE_URL/v1/tenants/$OC_TENANT/graph/road.cities/dijkstra" \
  -H "Authorization: Bearer $OC_TOKEN" \
  --data-urlencode "rel=connects" \
  --data-urlencode "src=NYC" \
  --data-urlencode "dst=SFO" \
  --data-urlencode 'weights_json={"NYC|CHI":2.0,"CHI|DEN":1.5,"DEN|SFO":1.2}'

200 OK

{ "cost": 4.7 }

Online schema migrations

Submit a diff, watch backfill progress, then cut over atomically. Aborts are allowed pre-cutover only. Every state transition is durably journaled.

POST /v1/tenants/:tenant/migrations - Submit a migration. Body: `{schema, diff}` where `diff` is a `Vec<oc_migrate::DiffOp>`.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/migrations" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "schema": "trading.orders",
    "diff":   [ { "AddColumn": { "name": "venue", "type": "str", "default": "NYSE" } } ]
  }'

200 OK

{
  "id":      "0192ab...",
  "tenant":  "01HW...ZZ",
  "schema":  "trading.orders",
  "state":   "Backfilling",
  "diff":    [ ... ],
  "progress": { "rows_seen": 0, "rows_total": null }
}

GET /v1/tenants/:tenant/migrations - List every migration the tenant has submitted (active + terminal).

curl "$OC_BASE_URL/v1/tenants/$OC_TENANT/migrations" \
  -H "Authorization: Bearer $OC_TOKEN"

200 OK

[ { "id": "...", "schema": "trading.orders", "state": "Backfilling", ... }, ... ]

GET /v1/tenants/:tenant/migrations/:id - Read one migration. Poll for backfill progress.

curl "$OC_BASE_URL/v1/tenants/$OC_TENANT/migrations/0192ab..." \
  -H "Authorization: Bearer $OC_TOKEN"
{ "id": "...", "state": "ReadyToCutover", "progress": { "rows_seen": 1240000, ... } }

POST /v1/tenants/:tenant/migrations/:id/cutover - Atomic cutover. Only legal in `ReadyToCutover` state.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/migrations/0192ab.../cutover" \
  -H "Authorization: Bearer $OC_TOKEN"
{ "id": "...", "state": "Completed", ... }

POST /v1/tenants/:tenant/migrations/:id/abort - Abort. Only legal pre-cutover. Once the migration is `Completed`, abort returns 409.

curl -X POST "$OC_BASE_URL/v1/tenants/$OC_TENANT/migrations/0192ab.../abort" \
  -H "Authorization: Bearer $OC_TOKEN"
{ "id": "...", "state": "Aborted", ... }

GET /v1/tenants/:tenant/migrations/_audit - Append-only audit log of every state transition (submit / cutover / abort / auto-cutover) with actor + UNIX timestamp.

curl "$OC_BASE_URL/v1/tenants/$OC_TENANT/migrations/_audit" \
  -H "Authorization: Bearer $OC_TOKEN"

200 OK

[
  { "id": "...", "schema": "trading.orders", "state": "Backfilling", "at_secs": 1714512000, "actor": "...", "event": "submit" },
  { "id": "...", "schema": "trading.orders", "state": "Completed",   "at_secs": 1714512042, "actor": "...", "event": "cutover" }
]

Replication (admin)

Lease-driven active-passive coordination. The lease holder is the sole writer; followers tail frames from the leader. These endpoints are operational, not application-facing - most tenants never call them.

GET /v1/replication/lease - Read the current lease (or null if vacant).

curl "$OC_BASE_URL/v1/replication/lease" \
  -H "Authorization: Bearer $OC_TOKEN"

200 OK

{ "epoch": 4, "holder": "writer-a", "expires_at_secs": 1714512030, "etag": "..." }

POST /v1/replication/lease - Try-acquire the lease. `ttl_secs` defaults to 30. Returns 409 if held by another writer.

curl -X POST "$OC_BASE_URL/v1/replication/lease" \
  -H "Authorization: Bearer $OC_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "holder": "writer-a", "ttl_secs": 30 }'
{ "epoch": 5, "holder": "writer-a", "expires_at_secs": 1714512060, "etag": "..." }

GET /v1/replication/frames?since_segment=&epoch= - Export the log from `since_segment` onwards as hex-encoded entries. Management-plane convenience; production followers stream raw bytes via the dedicated transport.

curl "$OC_BASE_URL/v1/replication/frames?since_segment=4&epoch=5" \
  -H "Authorization: Bearer $OC_TOKEN"

200 OK

["7b226c736e223a..."]

Health & observability

All three are public (no auth) so load balancers and Prometheus scrapers can probe without a credential.

GET /health - Liveness - process is up and the log is mounted.

curl "$OC_BASE_URL/health"

200 OK

{ "status": "ok" }

GET /ready - Readiness - the bare call reports storage health and answers 200 even when `status` is degraded. Use `?require=write` (or `?require=read`) for the strict probe; `pressure` carries the reason. Follower lag is not part of the check.

curl "$OC_BASE_URL/ready"
{ "write_ready": true, "status": "ready" }

GET /metrics - Prometheus exposition - request latencies, cache hits, log bytes, replication counts.

curl "$OC_BASE_URL/metrics"

200 OK (text/plain)

# HELP oc_query_latency_ms /v1/query end-to-end latency.
# TYPE oc_query_latency_ms histogram
oc_query_latency_ms_bucket{le="10"}  9218
oc_replication_frames_total          41702
oc_plan_cache_hits_total             41190
...

SQL - scope today

SELECT, INSERT, UPDATE and DELETE execute on the SQL endpoint. Do not re-issue a successful SQL mutation against the row API. The response kind and fields depend on the statement; see the SQL reference and transaction guide for commit boundaries.

© 2026 Silicoyn Technologies Pvt Ltd

On this page