The target can be a collection that has a feature extractor. Import goes
through the BYO write core and submits no extraction batch, so the vectors in
your export are the vectors that get stored. Nothing re-embeds them on the way
in, and bucket and object lineage on the imported rows is preserved.This says nothing about later runs. A trigger or a batch you start afterwards
treats these documents like any others.
1
Infer a mapping from a sample
POST /v1/collections/import/infer reads a sample of your export and
returns the source fields it found with a suggested source-to-target
mapping.fields and warnings. It runs on the sample alone, so nothing is
written and nothing is reserved.2
Validate the finished mapping
POST /v1/collections/import/validate-mapping checks the mapping you
settled on. mapping is required.ok plus errors. It flags four things: a missing root-identity
mapping, source and target types that disagree, a vector dimension that does
not match a known index, and source fields it does not recognise.3
Import
POST /v1/collections/{collection_identifier}/import reconstructs the
documents and writes them. mapping is required.reconstructed, imported, skipped, errors, warnings and
dry_run.Reading the result
A bad row does not stop the batch.
skipped counts rows that failed
reconstruction while imported counts the ones that were written, so a
partially-bad export gives you both, not an all-or-nothing outcome.Compare reconstructed against imported and skipped rather than checking
for an error status. A response with errors in it can still have written
most of the batch.Options
Related
- Documents & Search for the single-call BYO upsert
- Collection Lifecycle

