Vector

Package provisioning is one-click data add-ons: a SQL, key-value, document, vector, search or object store, wired straight into your app.

vector

GET /v1/vector/{name}

Returns one vector collection's metadata. It carries the collection's status and the gateway address it is reached at, and no username: the backend authenticates with a shared, out-of-band key rather than a per-collection credential, so there is no per-resource user to report.

DELETE /v1/vector/{name}

Deletes one vector collection from the shared backend and removes its metadata row. Answers 204 with no body; a second call is a 404.

GET /v1/vector/collections

Lists the vector collections with their size and geometry.

It reads the in-cluster Qdrant service: the collection list, then each collection's detail for its point count, vector dimension and distance metric. Per-collection detail is best-effort — one collection that fails to describe itself keeps its name and defaults (dimension 0, cosine) rather than blanking the whole panel — and an unreachable Qdrant answers 200 with an EMPTY list.

GET /v1/vector/stats

Totals the collections, vectors and storage across the vector store.

Every figure is summed from the same per-collection detail GET /v1/vector/collections returns, so the two panels can never disagree. An unreachable Qdrant answers 200 with all zeros rather than an error.

GET /v1/vector

Lists the caller org's vector collections. A collection is a logical resource inside an already-live shared backend, so every one of them is reached through the public gateway rather than at an instance of its own.

POST /v1/vector

Provision a vector collection for your org

Creates a vector collection inside the already-running shared vector backend and answers with the endpoint that reaches it.

name is the org-unique slug every physical name derives from, and must match ^a-z0-9?$. instance optionally BINDS the add-on to one of your app instances: the DSN is injected into that instance's addons secret as <KIND>_URL, switching the app off its built-in store and onto this one. Omit it and the connection string is yours to wire.

THE CREDENTIAL COMES BACK ONCE. The connection string and password are in this response and nowhere else — every read beside it omits the password — so a caller that does not keep them has to provision again. Where KMS is configured the password is sealed there and only a reference is persisted; where it is not, it is returned this once and stored nowhere. It is never held in plaintext.

Scoped to the caller's validated org (403 without one), which also namespaces the physical resource under a fixed-width hash, so two tenants can never fold onto one backend resource — a residual collision fails closed with 409 rather than silently sharing. A name already taken in your org is 409; an invalid name or instance slug is 400; a backend that refuses the create is 502. Where a later step fails after the backend resource already exists, it is torn back down rather than left orphaned.

Billing is gated BEFORE anything is created: an unfunded org — or, in the fail-closed default, an unreachable meter — gets the fleet-wide 402/503 and nothing is provisioned. The fee is per-kind and set by the deployment.

Request body — application/json

---

Vector guide · All Hanzo APIs · Interactive reference