Describe data in service language
Name people, households, businesses, or other useful records. Describe fields so service teams do not need to understand source tables.
Product · Protected Registry APIs
Give services read-only access to selected registry fields.
The registry owner connects an existing file, database, or registry system and defines which fields each public or partner service may read. The service receives only those fields, every request is recorded, and the source records stay with the authority.
The live demo shows read-only access to synthetic registry data through an API.
When to use Protected Registry APIs
Use it when a service needs several fields from an existing registry.
A registry does not need to be replaced before it can support another service. Registry Relay adds a protected, read-only API while the registry owner keeps the source and remains responsible for corrections and updates.
- A registry already exists in a file, database, or other system and must remain the official source.
- A public or partner service needs several agreed fields, not a complete export or direct source login.
- The registry owner needs a repeatable way to apply the same field rules and record each read.
How it works
The registry owner defines which fields each service can read.
Registry Relay applies that agreement to every request. It returns the permitted fields, refuses fields outside the agreement, and writes an audit record.
How selected data is provided
The registry owner controls which fields each service can receive.
-
Connect the existing source
The registry owner connects the file, table, or system it already maintains. Updates continue there.
-
Describe the useful data
The owner names useful records and fields in terms public and partner services understand.
-
Agree who can read which fields
Each service, purpose, and set of agreed fields is made explicit before any read is allowed.
-
Return selected data and record the read
The service receives the permitted fields. Fields outside the agreement are not returned. The request is recorded.
Registry owner
Source record stays with the authority
- Household reference agreed field
- District agreed field
- Enrolment status agreed field
- Home address not returned
- Payment details not returned
Field permissions
Permitted fields →
Other fields are not returned
Public or partner service
Selected data returned
- Household reference
- District
- Enrolment status
No source login and no copy of the full record.
Audit record Which service read which fields, for which purpose, what happened, and when.
Define the data access
Before connecting a service, define the data, purpose, and permitted fields.
The registry owner and service team document the access in terms that policy, security, and delivery teams can review.
Agree fields service by service
For each public or partner service, write down the purpose and the fields it may read. Fields outside that agreement are not returned.
Keep updates with the registry owner
Protected Registry APIs do not become a second registry. Corrections and updates continue in the source system controlled by its authority.
What the service can receive
Each service receives only the fields agreed for its purpose.
The source record remains in the registry. A request for any other field is refused and recorded.
What the service receives
Selected data from the agreed fields for this service and purpose, plus the information needed to understand the response.
What is not returned
Fields outside the agreement, source credentials, and the rest of the record are not returned to the service.
What stays with the registry owner
The source records stay with the authority. Every allowed or refused read leaves an audit record.
When a service needs evidence
Use Evidence Gateway when a service only needs proof of one fact.
Registry Relay returns selected data. When a service needs only one predefined, signed fact, use Evidence Gateway.
See the Evidence Gateway →Open-source components
The components used by Protected Registry APIs.
The technical documentation explains how each component is configured and deployed.
For your technical team