Skip to main content
POST
Bulk-submit a whole bucket as N auto-chunked, auto-queued batches

Authorizations

Authorization
string
header
required

Mixpeek API key, sent as Authorization: Bearer mxp_sk_.... Create one in Studio under Settings → API Keys, or with an admin key via POST /v1/organizations/users/{user_email}/api-keys. A missing header returns 403; an invalid or revoked key returns 401.

X-Namespace
string
header
required

Namespace id (ns_...), not the namespace name. This scopes the request rather than authenticating it, and it is required on every operation marked x-mixpeek-namespace-scoped.

Path Parameters

bucket_identifier
string
required

The bucket to ingest.

Body

application/json

Submit a WHOLE bucket as N auto-chunked, auto-queued batches in one call.

The server streams the bucket's objects (paginated), de-duplicates them, chunks them into chunk_size-object batches, and submits each — so the client makes ONE call instead of a paced chunk-loop. This kills the client-side cursor-overlap (409 storm), the 5k object-count timeout, and the no-whole-bucket frustration at once (phase 4). Each batch is accepted and QUEUED (accept-and-queue admission); poll the returned batch_group_id / batch ids for QUEUED -> PROCESSING.

collection_ids
string[] | null

Collections to process. Omit to auto-discover all collections sourced from this bucket (plus downstream dependencies).

filters
LogicalOperator · object | null

Optional filter to scope which objects are submitted. Omit to submit EVERY object in the bucket (the whole-bucket case).

chunk_size
integer
default:1000

Objects per batch. Clamped down to your tier's max_batch_size. Default 1000 — a good balance of parallelism and per-batch overhead. Sizing model: each batch runs as its own job whose workers scale at ~1 CPU worker per 500 objects up to a per-job worker ceiling, so 16k-20k objects saturates one job's parallelism — for large corpora (100k+ objects) prefer chunk_size 20000. Larger chunks don't run faster; they only raise the cost of a mid-run failure (progress is still resumable per-object via the processing ledger). Much smaller chunks pay one cluster cold-start each and queue behind your tier's concurrent-batch limit. Full guide: docs.mixpeek.com/operations/batch-ingestion-at-scale.

Required range: 1 <= x <= 50000
dedup_strategy
enum<string>
default:skip

How already-processed objects are handled (skip/replace/force).

Available options:
skip,
replace,
force
max_objects
integer | null

Optional cap on total objects streamed (safety bound for very large buckets). Omit to submit the whole bucket.

Required range: x >= 1

Response

Successful Response

Result of a whole-bucket bulk submit.

batch_group_id
string
required

Correlates all batches created by this call.

total_objects
integer
required

Distinct objects streamed (post-dedup).

total_batches
integer
required

Batches created.

submitted
integer
required

Batches accepted/queued successfully.

failed
integer
required

Batches that failed admission/submit.

chunk_size
integer
required

Effective per-batch object count used.

batches
BulkSubmittedBatch · object[]
required

Per-batch results with status + queue position.