Success of any G2P program delivery depends on access to beneficiary information across various foundational and functional registries.

An electronic registry is a structured & live identification system that gathers, saves, and maintains uniformed updated data or information on an entity, such as a patient, person, employee, student, or facility, and is constantly updated to serve as the entity's "Single Source of Truth" which is also verifiable. 
[ref: Sunbird-RC](

The scope of G2P Connect Registry interfaces is to enable federated minimal read-only data access between platforms using consented, interoperable specifications.

Federated Data Access

G2P Connect blueprint recommends federated data access using electronic registries over centralised data stores using below design principles:

  1. Social Protection Platforms MUST only have a cache copy of data

  2. Social Protection Platforms (SPP) MUST fetch ONLY the minimal or aggregated data. for e.g.,

    • Year of Birth or Age band instead of Date of Birth

    • Count by vehicle types instead of each vehicle info

    • Farmer land total acreage info instead of each identifiable land parcel info, etc.,

  3. Design/Implementation MUST allow minimal unified read only view of data as a cache. Implementations should avoid

    • Creating centralised data store(s)

    • Enabling capabilities to managing data attributes where legal mandate (i.e source of truth) is with another system(s)

    • Siloed data stores and with no capability to be in automated sync with source system(s)

Above principles are also applicable to other domains like Agriculture, Health, Education, etc, where system to system data access is required for service delivery.

G2P Connect recommends all systems involved in data exchange to enable below core features for interoperability using G2P connect Registry APIs:

  1. search - System in want of data shall pull from source system using search query

  2. subscribe - System in want of data shall register to data subscription service(s) using event(s) and additional filters (optional) with the source system.

  3. notify - Source system shall push data (on event or agreed frequency) to systems

Consented Data Sharing

User consent is a core tenant of any digital process or digital infrastructure integrations. Registry data access API design accomdates the concept of the concept to enable access to data / services.

Consent for data access is broadly classified in one of below operational modes with design aspects embedded into the core Registry API:

Consent TypeData ConsumerData Provider








User shares VC to directly avail service


G2P Connect recommends a digitally signed machine readable consent artefact for trusted data exchange between entities. In the absence of this, the existing paper based, techno-legal approach may work for entities to trust each other to exchange data using Registry APIs.

Use of "consent" attribute in APIs is recommend to implement this feature.

Authorised Data Sharing

In emergency scenarios where local laws allow intervention access to critical data on time is critical to reach out to beneficiaries in need to provide immediate relief. In these scenarios, obtaining regular consent may not practically possible.

Authorise attribute in search/subsribe requests enable data providers to share data to requesting entity. Authorise attribute may contain document reference that enable access to user data for specific purpose. Systems may audit this information for future references.


G2P Connect specifications is an attempt to enable interoperability both at Technology and Domain layers.

Technology interoperability of the APIs are based on design principles to enable communcation/messaging protocol between systems in a trusted manner. for e.g.,

  • Transport layer agnostic support using REST, file exchange or message queues

  • Sync/Async modes

  • Reliable message delivery

  • End to end payload security, non-repudiable capabilities

Auditability of data exchange requests is not in scope of these interfaces. As a best practice, registries that are providing data access services and systems consuming data should have good auditing mechanism built-in.

G2P Connect does recommend to implement consent and authorised data artefacts to request and service

Additionally, G2P Connect Registry APIs are designed to accomodate various Domain process flows, data/message structures for data exchange that are country/department/use case context specific.


  1. API specifications - html | yaml

  2. Discussion thread

Additional Information


  1. /registry/subscribe - Subscribe for an event with registry

  2. /registry/notify - Notify with data upon event or requested frequency

  3. /registry/search - Search request using key identifiers or simple queries

  4. /registry/on-search - Search results through callback

  5. /registry/txn/status - Status check request for Async API using txn id or ref id

  6. /registry/txn/on-status - Status check response through callback


  1. /registry/sync/search - Search request/response on same thread

  2. /registry/sync/subscriptions - Fetch registered subscriptions

  3. /registry/sync/unsubscribe - Unsubscribe to stop receiving data on notify API

  4. /registry/sync/txn/status - Async APIs status check invoked synchronously

Last updated

Content of this site is licensed under CC BY-SA 4.0 by CDPI