Registries live in files
Many real registries are a spreadsheet on a focal point’s laptop or a periodic database extract. Sharing them means emailing copies nobody can scope, revoke, or review.
Registry Relay · Expose
The registry in your spreadsheet becomes a governed service.
Registry Relay reads the files and tables a registry already lives in, CSV, XLSX, Parquet, or PostgreSQL, and publishes a protected, read-only API shaped around real-world entities, with access rules, field limits, and audit built in.
The live lab runs three Relay authorities on synthetic data, one of them straight from an XLSX workbook.
The problem it solves
The most common registry platform is a spreadsheet.
That is not a failure to fix by replatforming. It is the starting point to serve safely, today, while bigger modernization takes its time.
Full access or no access
Without a service layer in between, the institution’s choice is handing over the whole file or refusing the request. Either the partner over-receives or the service never launches.
Every integration starts over
Each partner negotiates a custom export with its own format, refresh, and side agreements. A year later nobody can say who holds which copy of what.
How it works
The source stays put. The service goes in front of it.
Your existing source
A CSV, XLSX workbook, Parquet file, or bounded PostgreSQL table stays where the institution keeps it.
Registry Relay
- Describe the entities
- Bind the source
- Set who may ask what
- Serve and audit
A protected consultation API
Read-only, scoped to fields and purposes, with standards-shaped views where partners need them.
Protected consultation
One registry source, many bounded answers.
Registry Relay serves metadata, selected fields, aggregate results, standards-shaped views, and audit records from an existing spreadsheet, Parquet file, CSV, or bounded database table, without becoming a bulk data-sharing pipeline.
Bounded response
Metadata
Schema and fields
Fields
Only approved columns
Aggregate
Summary, not rows
SP-DCI
Adapter view
Audit
Request recorded
Worked scenario
From a household register workbook to an eligibility service.
Describe what the file holds
The social protection agency’s household register is an XLSX workbook. A configuration names the real-world entities in it: households, individuals, and the fields each caller may see.
Bind it and set the rules
Registry Relay reads the workbook and serves it as entities, not cells. Access rules say which system may ask which question, with API keys or the government’s own identity provider.
Callers get answers, owners keep the file
A benefits portal checks household eligibility through the API. The workbook never leaves the agency, every request is audited, and the export-by-email era ends.
Open by design
Works with the data and the standards you already have.
Registry Relay is open source and adopts the formats and patterns the digital government ecosystem already uses, so the service you stand up today still fits the architecture you choose tomorrow.
- Reads CSV, XLSX, Parquet, and PostgreSQL sources where they already live.
- Speaks the formats partners expect: DCAT-AP catalogs, OGC API Features and Records, sync over SP-DCI (the social protection data-exchange interface), and field mapping to the PublicSchema shared vocabulary.
- Follows the protected consultation pattern of the GovStack Digital Registries building block.
- Read-only by design: provisioning and updates stay in the source system, which remains authoritative.
In the stack
Where Registry Relay sits.
The answering point runs three checks on every request. Registry Relay owns the first one: who may ask, for which purpose, over a protected, read-only surface, with every request in the audit trail. Each product runs on its own; together they share one answering point.
For your technical team