Decoupled Data API

Purpose

Provides a stable, consumer-shaped HTTP+JSON API for the DXP frontend and external integrators. It is the only path consumers use to read data.

Tech stack

Layer	Tech
Framework	TODO — FastAPI / Express / similar
Auth	Bearer tokens issued by CKAN / dedicated auth
Caching	TODO — Redis / CDN?

Repo location

TODO — link to the data-api repo.

Key responsibilities

Serve /v1/datasets, /v1/resources, /v1/search, /v1/organisations.
Enforce authentication and per-token scopes.
Translate CKAN's response shape into the consumer-facing envelope.
Cache responses where it's safe.
Apply rate limits.

What it does NOT do

Writes. It is read-only for consumers. Publishing happens through PortalJS Admin → CKAN.
Pass through CKAN's native API. Endpoints are deliberately shaped for consumers.
Own data. The source of truth is CKAN.

Dependencies

CKAN (read access)
Auth provider (token validation)
Cache layer (if used)

Key design choices

Decoupled from CKAN's API surface. We can evolve endpoints, paginate differently, and reshape response bodies without touching CKAN. See ADR 0001.
Versioned under /v1. Breaking changes happen at /v2, never silently.
Public + authenticated. Public datasets are reachable without a token; restricted ones require a scoped token.

Things to remember

The DXP must call this API, never CKAN directly.
Errors follow a stable envelope (API · Errors).
Every response carries X-Request-Id for traceability.

See also

Last reviewed: 2026-05-04