Skip to main content

Overview

Once your datasource is configured, you can push documents to POST /documents. Each document is identified by a unique id within its datasource. Indexing a document with an existing id will update it. The endpoint accepts either a single document object or an array in the same request body — there is no separate bulk route. Wrap your payload in documents:
For searchable content, you choose one of two approaches per document:
  1. Send file binaries --- Post the file as Base64-encoded bytes (binary_base64) with the correct mime_type. amberSearch handles content extraction server-side.
  2. Send text directly --- Post text_content with the content you want indexed.
Details: Content extraction (two options).

Index a single document

Send a POST request to the /documents endpoint:

Per-document outcomes

The pipeline returns one of these outcomes for each document so you can act on duplicates and skipped items:

Response codes for POST /documents

The HTTP response is 200 for any well-formed request, even if individual documents fail — inspect results[*].outcome for per-document state.

Index multiple documents

Send an array under documents. The server processes them sequentially and returns one result per document. A failure on one document does not abort the rest — each entry’s outcome is reported individually.

Document fields

For the full field reference (types, required/optional, descriptions) see Datasource & properties --- Standard document fields. A few field-level reminders:
  • file_type is required and must be one of the supported values listed under File types (or fetched from GET /file-types).
  • data_source_sub / data_source_sub_sub must be slug keys that match a sub declared on the datasource (word_word form, e.g. engineering, runbooks). amberSearch builds the compound storage values ({datasource}__{sub_key} etc.) for you.
  • author is a free-form string (an email or display name); it is not an object.
  • path is a breadcrumb string for display (e.g. Engineering / Runbooks / Onboarding). For the URL to open the document, use path_preview.

Content extraction (two options)

Send either binary_base64 or text_content in body, never both. Server processing --- Encode the file with standard Base64. Set mime_type to the real media type for that file. There is no closed list of supported types; use the correct IANA media type for whatever you upload. Client-supplied text --- Pass text_content with the content you want indexed.
Per-document binary cap: 100 MB (decoded). The cap is enforced by the downstream indexing service — the public /api/indexing proxy does not decode binary_base64 itself, so an oversize payload reaches upstream and is rejected there; the resulting error is forwarded verbatim. The default is controlled by indexing_api_max_binary_bytes; ask your operator if you need it raised.

Custom properties on documents

If your datasource has property definitions, send matching values in custom_properties on each document. Each entry is a { "name", "value" } pair where name matches a property definition key.
Values are validated against the datasource schema --- the property name must exist in the definitions, and the value must match the declared property_type. See Schema validation & errors for details.

Updating a document

To update an existing document, simply re-index it with the same id. The entire document is replaced with the new payload:
The pipeline re-indexes a document only when last_modified has changed or its access tokens have changed (any change to the permissions block — allow_anonymous_access, allowed_users, or allowed_groups). Edits to other fields (e.g. title, body, custom_properties) without bumping last_modified or changing permissions are treated as no-ops, and the response reports outcome: "already_indexed". Bump last_modified whenever you want content edits to take effect.
If neither last_modified nor the access tokens have changed, nothing is re-queued and the response reports outcome: "already_indexed".

Deleting a document

Response codes for DELETE /documents/{datasource}/{document_id}
Indexing a document does not make it immediately searchable. The server controls when new and updated documents are committed to the search index. This can take up to 2 hours depending on system load and commit scheduling. Do not rely on instant availability after a successful POST.

Schema validation & errors

Every document is validated against the datasource’s schema (object definitions, property definitions, and declared sub keys) before it is persisted. If validation fails the API returns HTTP 422 with this envelope:
Pydantic field-level errors (e.g. missing required fields, invalid id characters) use a different shape — the standard FastAPI HTTPValidationError, wrapped in {"detail": [...]} with one entry per offending field. The error_code envelope above is only used for the service-layer schema-validation cases listed below.

Error codes

Expected value types

In bulk requests, validation runs per document and failures are reported in results with outcome: "failed" and a message describing the cause. The other documents in the same batch are still processed.

Envelope summary

For 401 / 422-Pydantic / 500 responses that can come from any endpoint, see Common HTTP responses on the overview page.

Next steps

Permissions

Configure fine-grained access controls for your documents.

Datasource & custom properties

Adjust object types, sub-datasources, and property schemas on the datasource.