api_v1.meta_endpoints

Atlas view

api_v1.meta_endpoints

api_v1.meta_endpoints

One row per queryable endpoint, with filterable tags.

Try at /api ↗View in lineage ↗Report a data issue

First 5 rows · api_v1.meta_endpoints

snapshot 2026-05-12

endpoint	schema_name	table_name	tags	is_public_api	table_type
api_v1.activity_catalog	api_v1	activity_catalog	["layer:api_v1","cadence:irregular","eu_theme:SOCI","geo:kommune","provider:r…	true	VIEW
api_v1.coverage_gap_barnefattigdom	api_v1	coverage_gap_barnefattigdom	["layer:api_v1","cadence:annual","cadence:irregular","eu_theme:EDUC","eu_them…	true	VIEW
api_v1.distrikt_summary	api_v1	distrikt_summary	["layer:api_v1","cadence:irregular","eu_theme:GOVE","eu_theme:SOCI","geo:komm…	true	VIEW
api_v1.indicator_latest_values	api_v1	indicator_latest_values	["layer:api_v1","cadence:annual","cadence:irregular","eu_theme:EDUC","eu_them…	true	VIEW
api_v1.indicator_missing_kommuner	api_v1	indicator_missing_kommuner	["layer:api_v1","cadence:annual","cadence:irregular","eu_theme:EDUC","eu_them…	true	VIEW

Built from

This Atlas view joins data from the following upstream sources. Click through for provenance, methodology, and citation.

Atlas internal model ↗

mart_meta_sources

One row per ingested source: publisher, licence, coverage, freshness and what it feeds.

mart_meta_sources

Showing direct dbt parents. See full lineage in /lineage/ →

Columns

Column	Description
endpoint	Schema-qualified table/view identifier (`<schema>.<table>`). Primary key.
schema_name	One of `api_v1`, `marts`, `raw`.
table_name	Bare table/view name without schema qualification.
tags	`text[]` carrying the layer tag (`layer:<schema>`) plus inherited source tags via union semantics. Filter via PostgREST's `?tags=cs.{...}` array-contains operator.
is_public_api	`true` when `schema_name = 'api_v1'`. Lets clients distinguish stable-contract endpoints from the broader `marts.*` / `raw.*` surfaces that are queryable but not version-guaranteed.
table_type	`BASE TABLE` for tables (most `marts.*`, all `raw.*`) and `VIEW` for views (all `api_v1.*` wrappers). ⚠️ IN `api_v1` IT IS ALWAYS `VIEW` AND THEREFORE TELLS YOU NOTHING ON ITS OWN. All 17 public relations are views over a `marts.mart_*` relation; this column distinguishes them from `marts.*` and `raw.*`, not from each other. 🔴 IT DOES NOT PREDICT WHETHER `Prefer: count=estimated` CAN BE TRUSTED. Three cases, and the deciding property is whether the aggregation happened BEFORE the planner saw it: 1. the mart is a TABLE — 14 of 17. Its rows were counted by ANALYZE when it was built, whatever its query did, so the estimate is accurate. `indicator_summary` aggregates heavily and estimates fine, because the aggregating happened at build time. 2. the mart is a PLAIN VIEW — `brreg_enhet`. Row count propagates from the base table. Accurate. 3. the mart is an AGGREGATING VIEW — `kommune_ngo_summary` and `kommune_ngo_totals`, and only these. The planner must guess how many groups a GROUP BY will produce, and measured on the live API 2026-09-20 it guessed badly: kommune_ngo_summary exact 5 435 estimated 69 462 12.8x kommune_ngo_totals exact 357 estimated 6 946 19.5x ⚠️ AND SEPARATELY, `estimated = 1` DOES NOT MEAN ONE ROW. It is the planner's floor, so an EMPTY relation reports 1 — measured on activity_catalog, distrikt_summary and kommune_local_chapters, all of which hold zero rows and all of which are case 1. A consumer asking "is there any data here?" cheaply gets yes. ✅ Use `Prefer: count=exact`. The largest published relation is ~72 000 rows and an exact count is cheap; the estimate saves nothing worth being wrong about. 🔵 An earlier version of this description said the split was tables versus views. There are no tables in api_v1, so that rule was unusable — a consumer checking dim_kommune, a view that estimates exactly, would have concluded the documentation was wrong (urb-agents #1288).

Sample query

Live PostgREST query that returns the first 5 rows. URL adapts to the current host — local dev shows api-atlas.localhost; the deployed site shows the configured API base.

https://api-atlas.urbalurba.com/meta_endpoints?limit=5

About this view

One row per queryable endpoint, with filterable tags. The index of this API. One row per queryable Atlas endpoint, with tags inherited from upstream sources via the lineage graph and a `layer:<schema>` tag from the schema. Wraps to `api_v1.meta_endpoints` and backs the tag-filter catalogue at `/data` in the customer frontend (PLAN-007 phase 4). 🔵 THIS IS THE INDEX, SO IT SAYS WHERE THE OTHER TWO CATALOGUES ARE: `meta_sources` for one row per ingest source (licence, publisher, freshness), and `meta_dimensions` for one row per source × upstream dimension — what each coded column means and its value format. A consumer enumerating relations here should not have to read 19 descriptions to discover the second one (urb-agents #1335). Includes endpoints from `api_v1.*`, `marts.*`, and `raw.*` (Atlas's three open-by-default schemas; `private_marts.*` stays auth-gated and is excluded). Skips internal seeds prefixed `_` (`_sources_manifest`, `_sources_dimensions`) and any `dbt_*` diagnostic tables. Tag inheritance uses the **union** rule: a `mart_*` derived from many sources picks up every source's `provider:`, `topic:`, `geo:`, `cadence:`, and `eu_theme:` tag, deduped. Filter "involves something annual" beats "purely annual" — see PLAN-007 phase 3.2 for the design rationale.