Skip to main content
POST

Request body

database and collection are the current field names (formerly tenant_id and sub_tenant_id). The old names remain accepted as deprecated aliases for full backward compatibility.

Successful response

Always check if a database is ready before using it. Use Database Status to check.

What happens after database creation?

  1. Wait for provisioning: creation is asynchronous. Poll Database Status until infra.ready_for_ingestion is true.
  2. Default collection: No collection exists until your first write. The first time you ingest without an explicit collection, HydraDB creates the database’s default collection, which then stores all context written without a collection. Create additional collections at any time to scope data to users, teams, or projects.
  3. Retry failed databases: If a database appears in data.failed_databases from List Databases, re-create that database with POST /databases after addressing the reported issue. Poll status again before ingestion.
  4. Ingest: start ingesting context once the database is ready.
  5. Query: check ingestion status, and start querying once sources show graph_creation (searchable) or completed.

Defining metadata schema

Schema field names are immutable after database creation. You can add per-document free-form metadata fields at ingestion time, and add new database-level fields later with Update Metadata Schema, but updates are additive only: no delete, rename, or type change. Dense and sparse metadata lanes (enable_dense_embedding, enable_sparse_embedding) can only be declared here, at creation. Plan your schema before you create the database.
You can define a custom schema at database creation to declare the metadata fields you filter on, and to enable semantic/BM25 search over metadata text fields (enable_dense_embedding / enable_sparse_embedding). Each dense or sparse flag adds one vector field, so a field with both uses two; a database can have at most 6. Going over returns 400, as does declaring an ARRAY field. For detailed parameters, valid data types, limits, and comprehensive examples, see the metadata guide.

Errors

Common codes: 400 INVALID_INPUT (missing or invalid database, or an invalid schema), 403 FORBIDDEN (your plan’s database limit is reached), 409 DATABASE_ALREADY_EXISTS (the database is already in use; the deprecated POST /tenants route returns INVALID_INPUT instead), and 500 INTERNAL_ERROR (retry; if the message says the rollback also failed, delete the database first, then create it again). See Error Responses for the full list.

Authorizations

Authorization
string
header
required

API key sent as a Bearer token: "Bearer prefix.secret"

Body

application/json

Database creation request

database
string

Database is the canonical v2 name; TenantID is its deprecated alias and remains fully accepted. The TenantAliases middleware reconciles them before this binds, so TenantID is always populated.

Example:

"acme_corp"

database_metadata_schema
object[]

Defines database-level metadata fields for exact-match filtering and semantic/BM25 search. Canonical name; tenant_metadata_schema is a deprecated alias. Schema field names are immutable after database creation.

Example:
embeddings_dimension
integer

Override for the embedding vector dimension. Default: 1536.

Example:

1536

is_embeddings_tenant
boolean

Internal flag for embedding-only databases.

Example:

false

tenant_id
string
deprecated

deprecated: use database

Example:

"tenant_1234"

tenant_metadata_schema
object[]
deprecated

deprecated: use database_metadata_schema

Response

OK

data
object
Example:
error
object | null

Null on success; an object with code and message on failure.

Example:

null

meta
object
Example:
success
boolean

Whether the request succeeded.

Example:

true