Memories · Bulk write
POST /api/v1/memories/bulk — write many memories in one request.
Embedding defers by default on this path. Items written without a vector come
back with metadata.embedding_pending: true, and until it clears they are
reachable by keyword and by the non-semantic list, but do not compete on
semantic similarity — so a paraphrase search can miss a memory an exact-words
search finds.
APIKeyHeaderX-API-Key<token>Idempotency-Key?string|nullX-Bulk-Attempt-Id?string|nullapplication/json- body
tenant_id?Tenant IdTenant to operate on. Omit it and the tenant is resolved from the credential, which is what a tenant- or agent-scoped key already identifies — no prior /whoami call is needed. Supply it to act on a different tenant your credential may read (and for an admin key, which belongs to no single tenant, it is required).
""fleet_id?string|nullagent_id?string|nullitems*array<>1 <= items <= 100visibility?|nullSuccessful Response
application/json- response
Aggregate response from the bulk-write endpoint.
duplicates rolls up both duplicate_attempt and
duplicate_content for top-level metric continuity; per-item
detail lives in results. The route returns 200 when everything
succeeded and 207 Multi-Status when at least one item is in error —
callers must read per-item status and never infer success from
a 2xx alone.
created*Createdduplicates*Duplicateserrors*Errorsresults*array<>bulk_ms*Bulk Mscurl -X POST 'https://example.com/api/v1/memories/bulk' \ -H 'Content-Type: application/json' \ -d '{ "items": [ { "content": "string" } ]}'{ "created": 0, "duplicates": 0, "errors": 0, "results": [ { "index": 0, "client_request_id": "string", "status": "created", "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08", "duplicate_of": "15a4136f-d85d-4645-ade9-a6c6085b348c", "error": "string" } ], "bulk_ms": 0}