Commercient Data Lake / REST & GraphQL APIs
Expose exactly the tables, views, and stored procedures you choose, and endpoints exist immediately: full CRUD over REST, typed queries over GraphQL, both generated from your actual schema and secured by API keys that are enforced in the database, down to entity and field level.
CRUD endpoints per exposed entity, with filtering, paging, and stored-procedure execution. Atomic multi-row writes for transactional changes.
A typed schema over the same entities - query exactly the fields you need, with relationships where your schema defines them.
Row-change events by polling, server-sent events, or signed webhooks with retries - so downstream systems react to data instead of re-scanning it.
| Concept | How it behaves |
|---|---|
| API keys | Minted per purpose (dlake keys create or the console). A key can be full-access or scoped to specific entities, actions, and fields; scope is enforced by the database, fail-closed. |
| Authentication | One header on every call: X-API-Key: {tenant}:dlk_.... Key exchange, expiry, and immediate revocation are built in. |
| Row-level security | Visibility rules run inside SQL Server on every query, no matter which surface asked - REST, GraphQL, MCP, or CLI. |
| Audit | Administrative actions and data changes are logged and queryable. |
The schema builder (console, CLI, or MCP) is where entities become API. Create tables and views, then expose them; the API updates to match. Nothing is served that you did not expose, and a scoped key narrows that further per consumer.
The complete API guide — endpoints, conventions, examples, error shapes — ships
with your tenant: read it in the console's Help section, fetch it from the CLI with
dlake guide api, or have an AI agent pull it over MCP with get_api_guide.
The CLI page shows the fastest way to a working key.