> For the complete documentation index, see [llms.txt](https://docs.cdpi.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cdpi.dev/technical-notes/data-and-credentialing-infra/data-exchanges-system-to-system-data-sharing/platform-approaches-four-examples-1.md).

# Platform Approaches: Four Examples 1

The table below compares four national data exchange implementations across key technical dimensions. These are not competing standards; they represent different points on a spectrum, each reflecting a distinct set of choices about where trust is enforced, how participants are onboarded, and how much operational burden is placed on individual agencies. A country selecting or evolving its own approach should read this less as a ranking and more as a map of tradeoffs.

<table data-header-hidden><thead><tr><th></th><th></th><th width="149"></th><th></th><th></th></tr></thead><tbody><tr><td><mark style="color:purple;"><strong>Component</strong></mark></td><td><mark style="color:purple;"><strong>India - API Setu</strong></mark></td><td><mark style="color:purple;"><strong>Singapore - APEX</strong></mark></td><td><mark style="color:purple;"><strong>Estonia - X-Road</strong></mark></td><td><mark style="color:purple;"><strong>Uganda - UGHub (WSO2)</strong></mark></td></tr><tr><td><p><mark style="color:violet;"><strong>Publisher / Control plane</strong></mark></p><p><mark style="color:violet;"><strong>Where API providers design, version, configure and publish APIs</strong></mark></p></td><td>Yes — ministries upload OpenAPI 3.0 specs via the API Setu’s API Studio.</td><td>Yes — agencies publish and manage APIs via APEX’s API Lifecycle Portal.</td><td>Yes — Security Server configuration. Each member manages its own Security Server, registering services with the Central Server.</td><td>Yes — WSO2 API Manager Publisher portal. NITA-U centrally governs; MDAs publish their own APIs through the platform.</td></tr><tr><td><mark style="color:purple;"><strong>Data sharing layer</strong></mark></td><td></td><td></td><td></td><td></td></tr><tr><td><p><mark style="color:violet;"><strong>API Gateway</strong></mark></p><p><mark style="color:violet;"><strong>Runtime proxy that intercepts calls, applies policies, and routes to backend</strong></mark></p></td><td>Yes — APIs hosted on API Setu's infrastructure are proxied. APIs merely listed bypass the gateway.</td><td>Yes — central gateway for all Singapore government APIs.</td><td>No — peer-to-peer. Data flows directly between Security Servers. No central proxy.</td><td>Yes — WSO2 API Manager. All APIs proxied through NITA-U's deployment in the government data centre.</td></tr><tr><td><p><mark style="color:violet;"><strong>Key manager</strong></mark></p><p><mark style="color:violet;"><strong>Issues and validates credentials; controls who can access what</strong></mark></p></td><td>Validates OAuth token on every request. Identity verification at registration is manual. </td><td>Token anchored to Corppass or TechPass — a government-verified legal entity. Runtime token traceable to a verified organisation.</td><td>Certificates issued by a trusted CA at ecosystem join. Every request is signed with that certificate — identity is cryptographically bound to every message.</td><td>Validates OAuth tokens via WSO2 Identity Server. Supports eKYC. Better identity anchoring, but dependent on NITA-U's IAM configuration.</td></tr><tr><td><p><mark style="color:violet;"><strong>Traffic manager</strong></mark></p><p><mark style="color:violet;"><strong>Enforces rate limits and throttling across the gateway</strong></mark></p></td><td>Yes — rate limiting enforced at the Envoy layer for hosted APIs.</td><td>Yes — rate limiting enforced per agency and per API.</td><td>Not applicable. No central gateway. Each Security Server manages its own capacity.</td><td>Yes — WSO2 Traffic Manager enforces throttling policies centrally.</td></tr><tr><td><p><mark style="color:violet;"><strong>Micro integrator</strong></mark></p><p><mark style="color:violet;"><strong>Transforms payloads, orchestrates multiple backend calls, protocol mediation</strong></mark></p></td><td>No — neither synchronous orchestration nor event-driven patterns supported at the platform layer. Both are the consumer's responsibility.</td><td>No — both patterns must be handled at the application layer by the consuming agency.</td><td>No — X-Road is a transport and trust layer only.</td><td>Yes — WSO2 Micro Integrator handles synchronous orchestration. WSO2 Streaming Integrator adds event-driven capability.</td></tr><tr><td><mark style="color:purple;"><strong>Trust and security layer</strong></mark></td><td></td><td></td><td></td><td></td></tr><tr><td><p><mark style="color:violet;"><strong>Payload signing</strong></mark></p><p><mark style="color:violet;"><strong>Cryptographic proof that message content was not altered in transit</strong></mark></p></td><td>Not present — standard OAuth bearer tokens carry no payload integrity guarantee or authenticity guarantee</td><td>Built-in and enforced platform-wide. Self-signed JWTs ensure every call is tamper-proof and replay-proof.</td><td>Architectural and mandatory. Every message is signed by the sending Security Server and timestamped. Legally non-repudiable.</td><td>Manual configuration only. Not enforced platform-wide.</td></tr><tr><td><p><mark style="color:violet;"><strong>Audit logs</strong></mark></p><p><mark style="color:violet;"><strong>Record of who called what and when</strong></mark></p></td><td>Yes — Operator held.</td><td>Yes — Operator held.</td><td>Yes — distributed. Logs held independently by both data provider and consumer. Tamper-evident by design.</td><td>Yes — Operator held.</td></tr><tr><td><p><mark style="color:violet;"><strong>Encryption in transit</strong></mark></p><p><mark style="color:violet;"><strong>Data is encrypted between caller and server so it cannot be read by third parties</strong></mark></p><p><br></p><p><mark style="color:violet;"><strong>Plaintext exposure</strong></mark></p><p><mark style="color:violet;"><strong>Point where data is decrypted and briefly exists unencrypted</strong></mark></p></td><td><p>TLS only — standard HTTPS between consumer and API Setu endpoint.</p><p><br><br></p><p>At the API Setu gateway — decrypted on arrival, re-encrypted before forwarding to ministry backend.</p></td><td><p>TLS with identity anchored to Corppass/TechPass. Mutual TLS available.</p><p><br><br><br></p><p>At the APEX gateway — same exposure model as API Setu.</p></td><td><p>TLS between Security Servers. Data decrypted and re-encrypted at each hop.</p><p><br><br></p><p>At each Security Server only. No central broker — exposure limited to the two communicating parties.</p></td><td><p>TLS standard. WSO2 supports mutual TLS configurable per API.</p><p><br><br><br></p><p>At the WSO2 gateway in the government data centre. </p></td></tr><tr><td><p><mark style="color:violet;"><strong>Non repudiation</strong></mark></p><p><mark style="color:violet;"><strong>Legally binding proof that a specific party sent a specific message and that the recipient received it</strong></mark></p></td><td>Not present. No payload signing, no trust infrastructure binding, no trust timestamping, no signed receipts.</td><td>Partial — non-repudiation of origin is partially supported. JWT signing provides authenticity but key binding to a vetted legal entity via CA hierarchy is not enforced platform-wide. No signed receipts for non-repudiation of receipt.</td><td>Full non-repudiation. Origin: signing keys are certificate-bound to vetted legal entities via RIA's CA, and every message is trust-timestamped by an independent TSA. Receipt: Security Servers exchange signed acknowledgements.</td><td>Not present by default. WSO2 supports PKI-based signing and can be configured for trust-timestamping, but neither is enforced platform-wide. </td></tr><tr><td><mark style="color:purple;"><strong>Governance and discovery layer</strong></mark></td><td><br></td><td></td><td></td><td></td></tr><tr><td><p><mark style="color:violet;"><strong>Developer portal</strong></mark></p><p><mark style="color:violet;"><strong>Where consumers discover APIs, read docs, test in sandbox and subscribe</strong></mark></p></td><td>Yes — browse by ministry, sector, use case. One registration to subscribe; each API requires publisher approval.</td><td>Yes — Lifecycle Portal. Subscription workflow and sandbox. Identity anchored to Corppass/TechPass.</td><td>No built-in portal. Ecosystems layer a separate catalogue (e.g. RIHA in Estonia). Discovery requires bilateral agreement before data moves.</td><td>Yes — WSO2 Developer Portal. Entities browse, subscribe, and test via Try-it-out console (where configured by the API publisher). Governed by NITA-U.</td></tr><tr><td><mark style="color:violet;"><strong>Service registry</strong></mark></td><td>Yes — APIs listed by ministry and sector. Browsable via the developer portal. Consistency depends on ministry compliance with OpenAPI 3.0 standards</td><td>Yes — central registry maintained by GovTech. Standards enforced centrally.</td><td>Yes — maintained by the Central Server. Lists all member organisations and their security servers; individual service descriptions are held locally on each secuirty server.</td><td>Yes — WSO2 API Manager maintains a central registry. NITA-U governs what is published.</td></tr><tr><td><mark style="color:violet;"><strong>Consent Manager</strong></mark></td><td>Partial — DigiLocker flow requires explicit citizen consent via OAuth authorization code for Aadhaar-linked data. No uniform platform-level consent layer; consent implementation varies by API publisher</td><td>Not built into the platform. Consent handled at application level.</td><td>Not architectural. Estonia's data tracker allows citizens to see who accessed their data after the fact. Consent management layered separately for specific sectors.</td><td>Not built into the platform. Consent handled at application level.</td></tr><tr><td><p><mark style="color:violet;"><strong>Analytics</strong></mark></p><p><mark style="color:violet;"><strong>Tracks API usage, latency, errors, per-consumer breakdowns</strong></mark></p></td><td>Yes — usage dashboards. Publisher-level analytics available.</td><td>Yes — real-time monitoring, anomaly detection, unified dashboard managed by GovTech.</td><td>Limited — local logs at each Security Server. No central analytics dashboard.</td><td>Yes — WSO2 Analytics provides usage reporting. NITA-U holds centralised analytics.</td></tr></tbody></table>

1. Highlights reflect meaningfully different architectural choices