Docs

Small surface area. Production-facing semantics.

Phase A keeps the interface intentionally tight: catalog, detail, schema, search, export, stats, and admin key issuance. The goal is clarity, not breadth.

Small public surface, no internal workspace leakage
Product pages expose schema, search fields, and export semantics
Key-based access maps directly to quota, allowed products, and usage logs

Header convention

X-API-Key: pk_live_...
X-API-Key: <admin key for /api/v1/admin/*>

Response posture

Product routes return metadata-rich payloads so external teams can discover contract details without reverse-engineering the backend.

Endpoints

The full public contract in one scan.

GET/health

Root health check for deploy verification.

GET/api/v1/data/products

List all public products available to the caller.

GET/api/v1/data/products/{id}

Return product metadata and contract details.

GET/api/v1/data/products/{id}/schema

Return schema, search fields, and filters.

GET/api/v1/data/products/{id}/search

Execute live query against the product.

GET/api/v1/data/products/{id}/export

Export JSON or CSV with key-based permission checks.

GET/api/v1/data/stats

Return cache and product activity stats; monitor-enabled keys only.

POST/api/v1/admin/keys

Create a `pk_` key using the internal admin key.

Search example

One request to verify the shape.

curl -H "X-API-Key: pk_live_xxx" \
  "http://localhost:8000/api/v1/data/products/ca_sanctions_consolidated/search?q=Atabekov&limit=1"

What this proves

A caller can discover the product, inspect the schema, test the query shape, and only then wire production usage. That is the contract-first workflow this site is optimized for.