Skip to main content

Materialized Index

How the materialized field value index powers fast filters, when it updates automatically, and rebuilding it via POST /v1/search/materialize after bulk loads.

The materialized index pre-computes and stores extracted field values for every document — typed per field, one row per document/field pair — enabling sub-second filter queries even on large workspaces. The document filter (POST /v1/documents/filter), omnisearch, field autocomplete, and field values endpoints all execute against it, which is why their counts and results always agree with each other.

Each index row links a document to a field registry entry and carries the value in a typed slot — text, number, date, or boolean — matching the field's data type. The typing is what makes filter operators behave correctly without client-side casting: between on a date field compares dates, gt on an amount compares numbers, and the field_values map the filter inlines exposes the same typed slots back to you.

For normal operation you never touch it: single-document ingestion materializes values automatically during post-extraction processing. A manual rebuild via POST /v1/search/materialize exists for the cases where reads lag writes — after bulk ingestion of many documents at once, or after schema changes that redefine which fields exist. A stale index shows up as missing documents in filter results, missing suggestions in autocomplete, or a field whose occurrenceCount is high while its documentCount is 0.

The rebuild walks every completed document in the workspace in batches, upserting its values — it is idempotent, safe to re-run, and skips documents whose extraction has not finished (they materialize when they complete). The call is synchronous: the response returns once the backfill has walked the corpus, with processed reporting how many documents were materialized. A document that fails to materialize is logged and skipped rather than aborting the run, so processed can be lower than your corpus size.

Materialization walks the whole corpus and can be resource-intensive on large workspaces — avoid triggering it during peak usage, and do not run it in a loop. For incremental ingestion the index updates automatically per document.
POST/v1/search/materialize

Request

curl -X POST https://api.talonic.com/v1/search/materialize \
  -H "Authorization: Bearer $TALONIC_API_KEY"

Response

Response fields

statusstring`complete` when the backfill finishes.
messagestringHuman-readable confirmation.
processedintegerNumber of documents whose values were materialized during the backfill.

Response

{
  "status": "complete",
  "message": "Materialization triggered for all documents.",
  "processed": 1842
}

Errors

Error responses

401unauthorizedMissing or invalid API key.
403forbiddenThe API key does not have the write scope this endpoint requires.
429rate_limitedToo many requests. Retry after the period indicated in the Retry-After header.

In a typical bulk-ingestion workflow: upload the batch, wait until the documents report completed, then trigger one materialize call. After it returns, filter, autocomplete, field-values, and omnisearch all reflect the newly ingested data consistently.

Frequently asked questions

When do I need to manually trigger materialization?+
Only after bulk ingestion (e.g. uploading hundreds of documents at once) or schema changes, when filter or autocomplete reads look stale. For normal single-document uploads, the index updates automatically during post-extraction processing.
Is materialization idempotent?+
Yes. Running it multiple times produces the same result: existing materialized values are upserted, not duplicated, and documents still mid-extraction are skipped until they complete.
What does the processed count tell me?+
How many completed documents had their values materialized in this run. It can be lower than your total corpus when some documents are not yet completed or an individual document failed to materialize (failures are logged and skipped, never abort the run).
How do I recognize a stale index?+
Missing documents in filter results, missing suggestions in autocomplete, or a field whose occurrenceCount is high while documentCount is 0. One materialize call rebuilds the index for every completed document in the workspace.