GCRI · Digital Public Infrastructure
Interoperability and APIs
Interoperability lets systems run by different agencies, banks and firms exchange data and work together through common standards and application programming interfaces. It avoids lock-in, enables reuse and lets services be combined, and it requires governance, security and agreed meaning. This page sets out how interoperability is achieved, how it is measured, and what evidence serves the governments and standards bodies responsible.
How the work runs.
DPI service health
Interoperability and APIs · Payment switch · Today
- Transactions today2,943,7796Active
- Authentication success, %99.1Normal
- Availability, % this month99.78Normal
- Grievances open298Watch
Throughput
Rails
| Identity verify | 350 | 0.5 | Normal |
| Instant payment | 612 | 0.3 | Normal |
| Data exchange | 693 | 0.7 | Normal |
| Offline fallback | n/a | n/a | Standby |
Fig.DPI service health: example names and illustrative values, not a record or a live system.
Interoperability and APIs: how the risk develops.
Standards, exchange and reliability. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Standards make systems speak
Common data formats, vocabularies and protocols let systems exchange information without bespoke links for every pair.
APIs expose capabilities
Well-documented interfaces let other systems use a service, such as verifying identity or initiating a payment, under defined rules.
Meaning must match
Technical connection is not enough. Systems must agree on what data mean, or exchanges produce errors.
Governance keeps it working
Someone must maintain standards, approve participants, monitor use and resolve disputes, or interoperability decays over time.
How Interoperability and APIs is modelled, measured and tested.
The model, its assumptions, its data and its uncertainty, in the form a scientist or engineer would check. Structures follow published methods. The values drawn are illustrative, not findings.
Datasets and provenance
The data classes behind Interoperability and APIs and what is recorded about each before it is used.
| Data class | Provenance recorded | Resolution stated | Licence checked |
|---|---|---|---|
| Satellite imagery, optical and radar | sensor, processing level, acquisition date | pixel size and revisit | per scene |
| Reanalysis and climate model output | model, experiment, member, version | grid and time step | per release |
| In-situ sensors and gauges | station, instrument, calibration record | point and sampling rate | per network |
| Population and asset exposure | method, vintage, input sources | cell size and unit | per release |
| Boundaries and reference geography | producer, edition, date | scale | per edition |
- Lineage
- W3C PROV record from source to figure
- Principles
- FAIR: findable, accessible, interoperable, reusable
- Gaps
- shown as missing, never filled silently
Interoperability lets data move between domains' systems.
Findings are designed for the Methods and Technical series. Digital public goods follow the DPG Standard; records would follow the proposed Nexus Standards.
- Interoperability case studies.
- Open API specifications.
What is measured, and how well.
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Government services with open APIs | count | per assessment | API catalogues | OBSERVED |
| Data exchange transactions between agencies | count | monthly | Exchange platform logs | OBSERVED |
| Systems conforming to national interoperability standards | percent of systems | per assessment | Conformance testing | Published statistics |
| Reuse of shared components | count of services using shared components | per assessment | Architecture inventories | DECLARED |
| API availability | percent of time | monthly | Monitoring | OBSERVED |
| Interoperability frameworks adopted | status | per assessment | Policy review | Published statistics |
Where the evidence comes from.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| European Interoperability Framework and Interoperable Europe Act | Principles and legal basis for public sector interoperability | Public, EU terms |
| X-Road documentation (Nordic Institute for Interoperability Solutions) | Open-source data exchange layer used by several governments | Open source, MIT licence |
| OECD Digital Government Index and studies | Digital government practices across countries | Public, OECD terms |
| National API catalogues | Published government APIs | Open, licence per catalogue |
| GovStack specifications | Building block specifications for digital government | Open, licence to check |
Who decides, and what the evidence serves.
Digital Public Infrastructure prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Digital government agencies | Which standards and exchange layers to adopt | Maturity reviews; standards evidence |
| Standards bodies | Which specifications to maintain and update | Conformance evidence |
| Service owners | How to publish and secure APIs | API quality assessments |
Outputs this topic produces
- Interoperability maturity reviews
- API catalogue and quality assessments
- Semantic alignment guides for common data
- Evidence notes for interoperability governance
What experts ask.
Interoperability is what turns separate digital systems into infrastructure. It lets agencies share records instead of asking citizens to carry documents, lets payment providers connect to each other and lets states change vendors without rebuilding everything. Poor interoperability leads to duplicated systems, data silos and lock-in. But interoperability also spreads failures and data more widely, so it must be designed with security and rights in mind.
- Which standards and interfaces are used, who governs them and are they open for anyone to implement?
- Are data models and meanings shared, so that exchanged data are understood consistently?
- How reliable are interfaces under load, and what happens to dependent services when one fails?
- Can a component be replaced by another provider without breaking the systems around it?
Drivers and processes.
Interoperability works at technical, semantic, organisational and legal levels.
Interfaces and protocols
APIs, message formats and security protocols that let systems connect. Versioning and documentation determine whether they stay usable.
Shared meaning
Common data models and code lists so that a field means the same thing in every system. Mismatches cause silent errors.
Agreements and governance
Who maintains standards, how changes are agreed and what legal basis permits each exchange.
Many interoperability failures are not technical. Two agencies may use the same standard but define a household or an address differently; a ministry may lack the legal mandate to share data that it technically can exchange; a vendor may implement a standard with proprietary extensions. Durable interoperability therefore needs governance that keeps standards, meanings and legal permissions aligned over time.
How the evidence is built, and its limits.
- 01
Standards analysis
Review of standards for openness, maturity and adoption. A standard that is open on paper may still be closed in practice if implementation is costly.
- 02
Conformance testing
Tests that implementations follow a standard. Passing tests is necessary but not sufficient for real-world interoperability.
- 03
Reliability monitoring
Interface availability and latency data, applying data engineering, interoperability and stewardship. Operators may not publish them.
- 04
Architecture review
Analysis of how components connect and where single points of failure or lock-in arise.
How it is studied, and what the methods cannot say.
- 01Data engineering, interoperability and stewardshipSecure data exchange layers · Common data models · Consent-based sharingApplied here
- 02High-performance, cloud and edge computingCapacity planning for peaks · Multi-site and multi-provider hosting · Portability engineeringApplied here
- 03Cybersecurity and cryptographyThreat modelling DPI components · Protecting identity databasesApplied here
- 04Digital identity and public digital systemsAssurance design for services · Verifiable credentials · Exclusion error analysisApplied here
Where this page's references lead.
The bodies and documents this page is read against. Status and editions change; each link goes to the issuing body.
Questions and answers.
What is interoperability?
What is an API?
What is X-Road?
Does open source mean interoperable?
Is more interoperability always better?
Does the platform publish standards?
Contribute evidence from this page.
Reports is the Consortium's quarterly publication. What you know about this subject can become evidence, a case or a correction in the next edition, credited to you and published under CC BY 4.0 where it is your own work.
- EmailGateway GW-GCRISend it from this pageEvidence, a correction, a case, a method, a review, a translation or profile input. It arrives tagged with this page, so the editor who owns it receives it.
- ZenodoOpen depositDeposit it and submit to the communityPublish your own record on Zenodo with your ORCID iD, then submit it to the Reports community there. Curators review it; the DOI stays yours.
- ReportsGCRISee every way to contributeThe contribution types, how each is reviewed, what credit you receive, the licence and what is never accepted.
Never send personal data, sensitive infrastructure detail or anything you have no right to share. A contribution is reviewed before use; sending it confers no authorship or editorial rights, and sponsorship never buys a finding.
Bring a method, a dataset or a question.
Information and enquiries are open today. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.
Legal documents.
Maps, data and figures on this site are shown for context and general information. They are not advice, forecasts or warnings; the limits of the information are set out in the Disclaimers and Data Notices.