Database Tables
Goal: Publish a container's documents over HTTP, and control which operations exist.
Where a container's API is configured
Open the Database node's Inspector and choose Manage containers. Each container in that database has its own API settings, and those settings apply across the whole workspace.
- Select the Database node, open the Inspector
- Choose Manage containers
- Pick a container and switch on the operations you want published
Exposure lives on the container's own record. The address that reaches it is the store that owns the database — not a surface.
The endpoints you get
The table path is the document collection. There is no separate /documents segment.
GET /oi-api/data-stores/{store}/databases/{database}/tables/{table}
POST /oi-api/data-stores/{store}/databases/{database}/tables/{table}
GET /oi-api/data-stores/{store}/databases/{database}/tables/{table}/{documentId}
PUT /oi-api/data-stores/{store}/databases/{database}/tables/{table}/{documentId}
DELETE /oi-api/data-stores/{store}/databases/{database}/tables/{table}/{documentId}
The path names both a store and a database, and they have to agree. A database reached through a store that does not own it is refused as a wrong address — not as a permission problem, because the container's API settings were never consulted.
Addressing a single document
Cosmos addresses a document by id and partition key together. If your table is partitioned on anything other than /id, pass the value as a query parameter:
PUT /oi-api/data-stores/ops-store/databases/ops/tables/readings/rec-8842?partitionKey=device-17
On a PUT, the value may instead be read from the document body at the table's partition path.
Omit it on a partitioned table and the request is refused with 400 — the platform will not guess a partition key. This is the most common cause of an update or delete that looks broken on an otherwise healthy table.
Choosing which operations exist
Four operations can be published per container: Create, Read, Update, Delete.
The switches add. A container publishes only what it explicitly switches on — you turn them on, you do not turn them off.
A container with no API settings at all publishes nothing. An absent switch and an absent settings block mean the same thing: that operation is not available.
What "not switched on" actually does
An operation that is not switched on is absent from the listing, and refused with 403 if a client calls the path anyway.
/oi-api/openapi and the API Explorer show what your workspace publishes, not every path the platform could serve. An operation you never switched on does not appear there.
Two separate narrowings decide what you see in that listing, and neither implies the other: what the workspace has provisioned and chosen to expose, and what your own access rights permit you to see. An entry missing from your spec may be switched off, or may simply not be yours to see.
The 403 still matters, because a client that already knew a path does not consult the listing first.
When a request is refused, the reason is specific
Refusals are checked in order — database, then store ownership, then table, then whether the container is exposed at all, then the individual operation.
| What is wrong | Code | Status |
|---|---|---|
| No such database in this workspace | DATABASE_NOT_FOUND | 404 |
| That database is not in this store | DATABASE_NOT_IN_STORE | 404 |
| No such table in that database | TABLE_NOT_FOUND | 404 |
| The container publishes nothing | TABLE_NOT_EXPOSED | 404 |
| That operation is not switched on | OPERATION_NOT_EXPOSED | 403 |
| A partition key is needed and was not supplied | PARTITION_KEY_REQUIRED | 400 |
The order is deliberate: being told an operation is disabled, when the database is not in that store at all, sends you to fix the wrong thing.
What these endpoints do not do
A write through these endpoints is not attributable and leaves no record of itself.
The CosmosDB account belongs to you. Your own credentials reach the same container directly, without passing through this API at all — so there is no single point every write must cross, and no claim to the contrary would survive that. Which operations are published is an exposure decision made by whoever configures the container. That is a real and useful thing, and it is not a record of what happened.
If you need records kept as proof of what happened, that is a separate capability with an append-only store behind it — see Audit Event Log →. It does not read from these containers, and these containers do not feed it. It is also why a container declared as holding evidence is refused when you create it.
Next Steps
| If you want to... | Go to... |
|---|---|
| See full request and response shapes | REST API Reference → |
| Try the endpoints interactively | API Explorer → |
| Create or manage containers | Database Management → |
| Query this data with KQL | Warm Queries → |