> For the complete documentation index, see [llms.txt](https://docs.openg2p.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openg2p.org/platform.md). # Platform - [Roadmap](https://docs.openg2p.org/platform/roadmap.md): The direction of OpenG2P — where the platform, products, and community are headed over the next three years. - [Platform Architecture](https://docs.openg2p.org/platform/architecture.md) - [Platform Architecture](https://docs.openg2p.org/platform/architecture/platform-architecture.md) - [Async Processes - Tech Architecture](https://docs.openg2p.org/platform/architecture/async-processes-tech-architecture.md) - [Security Architecture](https://docs.openg2p.org/platform/architecture/security-architecture.md) - [Partner APIs](https://docs.openg2p.org/platform/architecture/security-architecture/partner-apis.md): Security design for Partner APIs - [Portal APIs](https://docs.openg2p.org/platform/architecture/security-architecture/portal-apis.md): Security design for Staff Portal API, Agent Portal API and Bene Portal API - [OpenG2P FastAPI Common](https://docs.openg2p.org/platform/architecture/openg2p-fastapi-common.md): The shared FastAPI framework and utilities that most OpenG2P Python services are built on — app bootstrap, config, data layer, auth, and JWS crypto. - [Versions](https://docs.openg2p.org/platform/architecture/openg2p-fastapi-common/versions.md): Version history of the OpenG2P FastAPI Common framework packages. - [Platform Services](https://docs.openg2p.org/platform/platform-services.md) - [Identity & Access Management](https://docs.openg2p.org/platform/platform-services/identity-and-access-management.md): IAM and RBAC concepts within OpenG2P - [High Level Design](https://docs.openg2p.org/platform/platform-services/identity-and-access-management/high-level-design.md) - [Authentication - Flow Diagram](https://docs.openg2p.org/platform/platform-services/identity-and-access-management/authentication-flow-diagram.md) - [RBAC in Product APIs](https://docs.openg2p.org/platform/platform-services/identity-and-access-management/rbac-in-product-apis.md) - [Staff Portal Application Registration](https://docs.openg2p.org/platform/platform-services/identity-and-access-management/staff-portal-application-registration.md): How applications (e.g. registries) self-register their Staff Portal tile, roles and permissions into the IAM Staff service at install time. - [Developer Install](https://docs.openg2p.org/platform/platform-services/identity-and-access-management/developer-install.md): This page provides comprehensive documentation for the installation of Openg2p IAM Service - [Security Controls](https://docs.openg2p.org/platform/platform-services/identity-and-access-management/security-controls.md): Token Handling, Headers, CORS & CSRF Protection - [Versions](https://docs.openg2p.org/platform/platform-services/identity-and-access-management/versions.md): IAM Service Versions - [Staff UI](https://docs.openg2p.org/platform/platform-services/identity-and-access-management/staff-ui.md) - [Requirements](https://docs.openg2p.org/platform/platform-services/identity-and-access-management/staff-ui/requirements.md): Design & Requirements - [Audit Manager](https://docs.openg2p.org/platform/platform-services/audit-manager.md): A centralised audit-event service for OpenG2P. Accepts structured audit events over HTTP, buffers through Kafka, and persists them to a partitioned PostgreSQL table for long-term retention and forensi - [Functional Specifications](https://docs.openg2p.org/platform/platform-services/audit-manager/functional-specifications.md): Event schema (CloudEvents envelope + OpenG2P data conventions), mapping to Postgres columns, how to emit audit events from API calls, naming conventions, and PII handling. - [API Reference](https://docs.openg2p.org/platform/platform-services/audit-manager/api-reference.md): REST API reference for the Audit Manager — rendered directly from the live OpenAPI 3.1 spec committed to the repo. - [Technical Architecture](https://docs.openg2p.org/platform/platform-services/audit-manager/technical-architecture.md): Design choices behind the Audit Manager — why each alternative was rejected, scalability model, reliability & delivery guarantees, and the partitioning / retention strategy. - [Deployment](https://docs.openg2p.org/platform/platform-services/audit-manager/deployment.md): Deployment guide for the Audit Manager — local development with Docker Compose, Helm chart installation, configuration reference, operational runbook, and security considerations. - [Testing](https://docs.openg2p.org/platform/platform-services/audit-manager/testing.md): Test plan for the Audit Manager — unit tests (pydantic schema), end-to-end smoke test against docker compose, concurrent load test, and the Postman collection. - [Integration with Registry](https://docs.openg2p.org/platform/platform-services/audit-manager/integration-with-registry.md): How OpenG2P registry services integrate with the Audit Manager. Covers two BFF integrations — Staff Portal API and Partner API — that share the same middleware shape but adapt to their respective auth - [Local Install — Staff Portal API](https://docs.openg2p.org/platform/platform-services/audit-manager/integration-with-registry/local-install.md): Step-by-step guide to run openg2p-registry-staff-portal-api on a local developer machine. Includes every fix needed beyond the upstream README, with macOS / Apple Silicon notes called out explicitly. - [Audit Middleware — Staff Portal API](https://docs.openg2p.org/platform/platform-services/audit-manager/integration-with-registry/audit-middleware.md): AuditMiddleware for the Registry Staff Portal API — design, files changed, configuration, and how to verify audit events land in the Audit Manager Postgres store. - [Audit Middleware — Partner API](https://docs.openg2p.org/platform/platform-services/audit-manager/integration-with-registry/partner-api.md): AuditMiddleware for the Registry Partner API — the variant adapted to signature-based auth, with controller opt-in hooks for richer actor identity and outcome tracking. - [Verification — End to End](https://docs.openg2p.org/platform/platform-services/audit-manager/integration-with-registry/verification.md): End-to-end smoke test confirming the Staff Portal API → Audit Manager integration works: a Keycloak-authenticated API call lands as a row in the cluster's audit\_events table within seconds, with the f - [ID Generator](https://docs.openg2p.org/platform/platform-services/id-generator.md): A service that generates unique, random numeric IDs for multiple consuming applications with pre-generated pools, Verhoeff checksum, and multi-ID-type support. - [Functional Specifications](https://docs.openg2p.org/platform/platform-services/id-generator/functional-specifications.md): Functional specification for the ID Generator service — ID types, generation rules, filters, pool management, and exhaustion handling. - [API Reference](https://docs.openg2p.org/platform/platform-services/id-generator/api-reference.md): API reference for the ID Generator service — endpoints, response envelope, error codes, and HTTP status codes. - [Technical Architecture](https://docs.openg2p.org/platform/platform-services/id-generator/technical-architecture.md): Technical architecture of the ID Generator service — async stack, database design, concurrency patterns, and Kubernetes deployment. - [Deployment](https://docs.openg2p.org/platform/platform-services/id-generator/deployment.md): Deployment guide for the ID Generator service — Helm chart installation, configuration, Docker setup, and local development. - [Testing](https://docs.openg2p.org/platform/platform-services/id-generator/testing.md): Test plan for the ID Generator service — test categories, execution, and reporting. - [Master Data Service (Catalogue)](https://docs.openg2p.org/platform/platform-services/master-data-service.md): The platform's catalogue of reference data: versioned datasets and geography, with approvals, a change feed and an opt-in public catalogue - [Concepts](https://docs.openg2p.org/platform/platform-services/master-data-service/concepts.md): The ideas behind MDS in plain language: datasets, entries and typed fields, the geography, versions and effective dates, fixed codes and retired entries, reading latest, pinned, as of a date or by rel - [Geography and Boundary Changes](https://docs.openg2p.org/platform/platform-services/master-data-service/geography.md): How MDS represents geography and administrative boundaries: P-codes, one version for the whole geography, units that are never deleted, change events (split, merge, rename, recode, reparent, boundary - [Change Control and Approvals](https://docs.openg2p.org/platform/platform-services/master-data-service/change-control.md): How datasets and geography change in MDS: drafts, submission, approval by maker-checker or through AWE, publication with an effective date, settings that apply at once, permissions, audit and the deli - [For Consumers](https://docs.openg2p.org/platform/platform-services/master-data-service/consumers.md): Who reads MDS and how, and how services should read datasets and geography: latest, pinned or as-of reads, caching, the change feed, pinning in configuration, storing the version used, retired entries - [Public Catalogue](https://docs.openg2p.org/platform/platform-services/master-data-service/public-catalogue.md): The opt-in, anonymous, read-only public catalogue of MDS: what it shows, visibility and licence, downloads, DCAT and SKOS, and how to switch it on - [Admin Guide](https://docs.openg2p.org/platform/platform-services/master-data-service/admin-guide.md): For catalogue administrators: how changes are made in the Master Data admin UI, who can do what, steps to recode an entry, change geography and load a newer country pack, and what to know when adding, - [Country Packs](https://docs.openg2p.org/platform/platform-services/master-data-service/country-packs.md): What a country pack is, how to build one for a new country, and how MDS loads and upgrades it (the first version is published at once, later loads become drafts) - [Design Decisions](https://docs.openg2p.org/platform/platform-services/master-data-service/design-decisions.md): Why the Master Data Service (Catalogue) is designed the way it is: why reference data needs versions, why a service of its own, versioning per dataset, effective dates per version, no expiry date on e - [Deployment](https://docs.openg2p.org/platform/platform-services/master-data-service/deployment.md): How the Master Data Service is installed (inside commons-services), every setting that matters at install, the object store for boundaries, approval through AWE and the public catalogue host - [API Reference](https://docs.openg2p.org/platform/platform-services/master-data-service/api-reference.md): Every Master Data Service (Catalogue) endpoint and the data model behind it: datasets, geography, releases, the change feed, the original /attributes and /geo endpoints, sample people and the public c - [Standards](https://docs.openg2p.org/platform/platform-services/master-data-service/standards.md): Every standard the Master Data Service (Catalogue) uses or follows, where it is used and how fully: catalogue metadata, datasets, geography, licences, formats, events, HTTP and security. - [Software Versions](https://docs.openg2p.org/platform/platform-services/master-data-service/versions.md): Software versions of the OpenG2P Master Data Service (MDS) and its changelog. - [Approval Workflow Engine (AWE)](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine.md): A generic, configurable multi-stage approval workflow engine for OpenG2P. Caller services post artifacts for approval; AWE resolves stages and approvers, tracks decisions, and notifies callers via sig - [Versions](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/versions.md): Version history of the OpenG2P Approval Workflow Engine (AWE). - [Releases](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/releases.md) - [v1.0.0](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/releases/v1.0.0.md): AWE Release Notes for v1.0.0 - [Scenarios catalog](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/scenarios.md) - [Functional Specifications](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/functional-specifications.md): Policy model, stage modes, approver rule types, context semantics, skip rules, request lifecycle state machine, webhook contract, and FAQ. - [API Reference](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/api-reference.md): REST API reference for the Approval Workflow Engine — rendered directly from the live OpenAPI 3.1 spec committed to the repo. - [Error codes](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/error-codes.md) - [Technical Architecture](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/technical-architecture.md): Design choices behind the Approval Workflow Engine — why each alternative was rejected, scalability model, delivery guarantees, engine state machine, and approver-resolution caching. - [Integration with Registry](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/integration-with-registry.md) - [Deployment](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/deployment.md): Deployment guide for the Approval Workflow Engine — local development with Docker Compose, Helm chart installation, configuration reference, Keycloak prerequisites, operational runbook, and security c - [Testing](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/testing.md): Test plan for the Approval Workflow Engine — hermetic pytest smoke tests against in-memory SQLite, what they cover, and how to run against real Postgres. - [How-To Guides](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/how-to.md) - [Run stages in parallel](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/how-to/parallel-stages.md) - [Skip a stage based on context](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/how-to/conditional-skip.md) - [Configure SLA escalation](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/how-to/sla-escalation.md) - [Set up out-of-office delegation](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/how-to/delegation.md) - [Mark a required (must-approve) approver](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/how-to/required-approver.md) - [Add a non-blocking observer](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/how-to/observers.md) - [Forbid self-approval & repeat approvers](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/how-to/segregation-of-duties.md) - [Reassign a stuck task](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/how-to/reassign-task.md) - [Use a Keycloak client role in a rule](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/how-to/client-role-rule.md) - [WebSub](https://docs.openg2p.org/platform/platform-services/websub.md): Shared WebSub hub used by OpenG2P products to register topics and deliver events to subscriber callbacks. - [Subscription and delivery](https://docs.openg2p.org/platform/platform-services/websub/subscription.md): How a publisher registers a WebSub topic, how a subscriber proves its callback, and how delivery is signed. - [Deployment](https://docs.openg2p.org/platform/platform-services/websub/deployment.md): Commons deployment of the MOSIP WebSub hub and consolidator, including Kafka and hub authentication. - [Partner Management](https://docs.openg2p.org/platform/platform-services/partner-management.md): OpenG2P's central registry of partners, their public keys and their access policies, read by other modules over an internal API. - [Versions](https://docs.openg2p.org/platform/platform-services/partner-management/versions.md): Version history of the OpenG2P Partner Management service. - [Functional Specifications](https://docs.openg2p.org/platform/platform-services/partner-management/functional-specifications.md): Partner Management entities (partners, keys, access policies, requests), their lifecycles, and how staff onboard partners, rotate keys and change policies. - [Creating and Changing Policies](https://docs.openg2p.org/platform/platform-services/partner-management/creating-and-changing-policies.md): Step by step in the Partner Management staff portal: give a partner an access policy (registry or use case), edit, widen or revoke it, approve the request, and check that PM serves it. - [API Reference](https://docs.openg2p.org/platform/platform-services/partner-management/api-reference.md): Partner Management APIs — staff APIs for partners, keys, policies and requests, and the internal partner API other modules use to fetch keys and policies. - [Technical Architecture](https://docs.openg2p.org/platform/platform-services/partner-management/technical-architecture.md): Partner Management components, staff authentication, data model (partners, keys, policies, requests), the key- and policy-fetch paths and auditability. - [Integration — consuming partner keys and policies](https://docs.openg2p.org/platform/platform-services/partner-management/integration.md): Handover note for an OpenG2P service that needs to verify partner signatures or check what a partner may ask for — how to consume partner public keys and access policies from Partner Management (PM). - [Deployment](https://docs.openg2p.org/platform/platform-services/partner-management/deployment.md): Installing Partner Management — images, Helm chart, key values, routing, migrations, uninstall and configuration. - [Testing](https://docs.openg2p.org/platform/platform-services/partner-management/testing.md): Partner Management automated tests, a manual smoke test without Keycloak, and the UI build check. - [Verifiable Credentials](https://docs.openg2p.org/platform/platform-services/vc-issuance.md): Issuing Verifiable Credentials from OpenG2P data (Registry first) with MOSIP Inji Certify — and, crucially, how a citizen holds and presents them. Phase 1 is paper-based; Phase 2 is a self-owned smart - [Custody Options & Strategy](https://docs.openg2p.org/platform/platform-services/vc-issuance/custody-options-and-strategy.md): How a citizen holds and presents a Verifiable Credential — the three options (paper, hosted wallet, device wallet), who each serves, an honest comparison, and why OpenG2P does paper first and self-own - [Phase 1 — Paper Credential](https://docs.openg2p.org/platform/platform-services/vc-issuance/phase-1-paper-credential.md): Phase 1 — agent-assisted issuance of a signed, printable credential (PDF with an offline-verifiable QR) from OpenG2P Registry data, gated by the beneficiary's own eSignet authentication and verified w - [Signatures, Keys and the QR](https://docs.openg2p.org/platform/platform-services/vc-issuance/signatures-keys-and-the-qr.md): What an issuance actually produces — two signed documents, two keys, one QR — which component builds each part, which signature a verifier checks, and what has to be true before anyone can verify anyt - [Registry Data Connector](https://docs.openg2p.org/platform/platform-services/vc-issuance/registry-data-connector.md): How Inji Certify gets the citizen's claims — two paths. Phase 1 PUSHES claims from the Agent Portal API (Certify stays decoupled); the wallet flow PULLS via a custom DataProvider plugin with configura - [Verification](https://docs.openg2p.org/platform/platform-services/vc-issuance/verification.md): How a printed credential's QR is checked — the Agent Portal's verification screen, the trust anchor it resolves keys from, and why OpenG2P runs only Inji Verify's verify-service. - [Deployment](https://docs.openg2p.org/platform/platform-services/vc-issuance/deployment.md): Deploying VC issuance and verification with Helm — the charts, their parameters, the jobs they run, and how to test the result. - [Managed VC Definitions (proposal)](https://docs.openg2p.org/platform/platform-services/vc-issuance/managed-vc-definitions.md): PROPOSAL: move credential templates out of Helm into approved, versioned registry metadata with an admin UI. Not built. - [Local Developer Trial](https://docs.openg2p.org/platform/platform-services/vc-issuance/local-setup.md): A verified local run of the Phase-1 push flow — the Agent Portal API reads a real registrant, pushes claims to Inji Certify, gets an Ed25519-signed credential, and renders a printable PDF with a QR. N - [Wallet Handover (Phase 1.5)](https://docs.openg2p.org/platform/platform-services/vc-issuance/wallet-handover.md): Phase 1.5 — the agent hands a credential straight into the citizen's own wallet at the counter, using an OpenID4VCI credential offer. Same authentication, same Certify, same push as paper; only the de - [Phase 2 — Device Wallet](https://docs.openg2p.org/platform/platform-services/vc-issuance/phase-2-device-wallet.md): Phase 2 (future) — self-owned smartphone wallets (Inji Mobile). The self-sovereign upgrade for citizens who have a smartphone. - [Supporting VC 2.0 (TODO)](https://docs.openg2p.org/platform/platform-services/vc-issuance/supporting-vc-2-0.md): TODO: move issued credentials from W3C VC Data Model 1.1 to 2.0. Not started. An implementation brief covering what to change, what to keep, and what to test. - [Consent Management](https://docs.openg2p.org/platform/platform-services/consent-management.md): The OpenG2P Consent Manager: the Policy Decision Point for outbound data sharing. It holds the subject's consent, checks it against the partner's access policy in Partner Management, and tells the reg - [Partner Integration Guide](https://docs.openg2p.org/platform/platform-services/consent-management/partner-integration-guide.md): End-to-end guide for a partner (data consumer) who wants to fetch a beneficiary's data from an OpenG2P registry — onboarding, keys, policy, obtaining consent (through the Consent Manager, or signing y - [Design](https://docs.openg2p.org/platform/platform-services/consent-management/design.md): Design of the OpenG2P Consent Manager: key terms, the main design decisions, and a guide to the design pages. - [Architecture](https://docs.openg2p.org/platform/platform-services/consent-management/design/architecture.md): Architecture of the Consent Manager: the PDP/PEP model, one shared CM per install, the API audiences, and the components. - [Data model](https://docs.openg2p.org/platform/platform-services/consent-management/design/data-model.md): The entities the Consent Manager stores, and the JSON-LD documents it exchanges: the partner-signed consent object, the consent artefact, and the Kantara / ISO 27560 consent receipt. - [Verification & enforcement](https://docs.openg2p.org/platform/platform-services/consent-management/design/verification-and-enforcement.md): The primary flow: a registry asks the Consent Manager whether it may answer a partner. The kinds of consent a request can carry, the validation pipeline, how the partner's policy from Partner Manageme - [Partner Management integration (keys and policies)](https://docs.openg2p.org/platform/platform-services/consent-management/design/partner-management-integration.md): How the Consent Manager reads partner keys and access policies from Partner Management: the partner ID convention, the endpoints it calls, which policy each check uses, per-pod caching, and fail-close - [Registry integration (the PEP side)](https://docs.openg2p.org/platform/platform-services/consent-management/design/registry-integration.md): How an OpenG2P registry (the PEP) uses the Consent Manager: where the consent sits in a DCI search, consent by lookup, subject and field enforcement, the data-scope catalogue, and the registry's setti - [Exchange consent tokens (Agri Stack Exchange)](https://docs.openg2p.org/platform/platform-services/consent-management/design/exchange-receipts.md): Agri Stack Exchange — one Consent Manager codebase in two roles: the Exchange CM issues signed consent tokens (checking the partner's policy for the use case), a department CM accepts them from a trus - [Consent lifecycle](https://docs.openg2p.org/platform/platform-services/consent-management/design/consent-lifecycle.md): The secondary flow: originating consent through the Consent Manager (request, authenticate, approve, artefact, receipt), and the revocation and expiry that apply to every consent. - [Consent collection](https://docs.openg2p.org/platform/platform-services/consent-management/design/consent-collection.md): How a partner seeks a subject's consent and how the subject gives it: the scenarios (in person with a form is built), national-ID login, identifiers and demographics, the partner's copy of a consent, - [Security & trust](https://docs.openg2p.org/platform/platform-services/consent-management/design/security-and-trust.md): The Consent Manager's trust model: keyholders, signing and key management (partner keys from Partner Management, the CM's own .p12 key and JWKS), the algorithm-confusion guard, ID-token checks, replay - [Standards & best practices](https://docs.openg2p.org/platform/platform-services/consent-management/design/standards-and-best-practices.md): How the Consent Manager aligns with Kantara / ISO 27560, GDPR, DEPA / Account Aggregator and DCI / OIDC, and what is built against each. - [API Reference](https://docs.openg2p.org/platform/platform-services/consent-management/api.md): Conventions of the Consent Manager HTTP API: endpoints by audience, authentication, the decision and error model, the shared reason codes, and the staff endpoints (decision log, consent verification, - [Verification API](https://docs.openg2p.org/platform/platform-services/consent-management/api/verification-api.md): The partner API, used by registries and the Composite: validate a consent (by ID, by lookup, a partner-signed object or a consent token), consent and consent-token status, signed receipts, and the CM' - [Consent Lifecycle API](https://docs.openg2p.org/platform/platform-services/consent-management/api/consent-lifecycle-api.md): The origination API: create a consent request, bind an authentication context from an OIDC ID token, approve or deny, and revoke. Runs on the beneficiary API (off by default). - [Subject API](https://docs.openg2p.org/platform/platform-services/consent-management/api/subject-api.md): Subject-facing API for GDPR data-subject rights: list one's consents and receipts, and withdraw consent. Runs on the beneficiary API (off by default). - [Development](https://docs.openg2p.org/platform/platform-services/consent-management/development.md): Developing the Consent Manager: technology stack, repository layout, local setup, tests and configuration. - [Deployment](https://docs.openg2p.org/platform/platform-services/consent-management/deployment.md): Deploying the Consent Manager: images, Helm chart, all settings (Partner Management, signing key, partner portal, national-ID login, Exchange roles), Keycloak provisioning, scaling, and the in-cluster - [Connector](https://docs.openg2p.org/platform/platform-services/connector.md): The integration layer between external data sources and the OpenG2P Registry. Receives or fetches data, verifies who sent it, reshapes each record, and delivers signed batches to the Registry Partner - [Functional Specifications](https://docs.openg2p.org/platform/platform-services/connector/functional-specifications.md): How the Connector is configured and how data moves through it: pipelines, transports, partner trust, receiving, fetching, delivery, failures, and day to day operation. - [Technical Architecture](https://docs.openg2p.org/platform/platform-services/connector/technical-architecture.md): Components of the Connector, how data and job messages move between them, and what the connector keeps in its database. - [Deployment](https://docs.openg2p.org/platform/platform-services/connector/deployment.md): Runtime roles of the Connector image, how they scale, what the connector depends on, and how each role is monitored. - [Data Sharing](https://docs.openg2p.org/platform/platform-services/data-share.md) - [OpenG2P - IUDX](https://docs.openg2p.org/platform/platform-services/data-share/openg2p-iudx.md): Data Share - [Privacy & Security](https://docs.openg2p.org/platform/platform-services/privacy-and-security.md) - [Key Manager](https://docs.openg2p.org/platform/platform-services/privacy-and-security/key-manager.md) - [PyJWTCryptoHelper](https://docs.openg2p.org/platform/platform-services/privacy-and-security/pyjwtcryptohelper.md) - [Security Audits](https://docs.openg2p.org/platform/platform-services/privacy-and-security/security-audits.md) - [Security Audit 2025 June](https://docs.openg2p.org/platform/platform-services/privacy-and-security/security-audits/security-audit-2025-march.md) - [System Monitoring](https://docs.openg2p.org/platform/platform-services/system-monitoring.md) - [Setup & Configuration](https://docs.openg2p.org/platform/platform-services/system-monitoring/setup-and-configuration.md) - [Dashboards & Viewing Logs](https://docs.openg2p.org/platform/platform-services/system-monitoring/dashboards.md) - [Operations Guide](https://docs.openg2p.org/platform/platform-services/system-monitoring/operations.md) - [Reporting & Analytics](https://docs.openg2p.org/platform/platform-services/reporting-and-analytics.md): How a registry's records become reports — the reporting views underneath, the dashboards on top, and the map drill-down beside them. - [Reporting views](https://docs.openg2p.org/platform/platform-services/reporting-and-analytics/reporting-views.md): The views every report reads — generated from the registry's own schema, refined by a short declaration, with personal data withheld by default. - [Dashboards](https://docs.openg2p.org/platform/platform-services/reporting-and-analytics/dashboards.md): Apache Superset dashboards — shipped by each registry, imported during its own install, and how a country changes them. - [Map drill-down](https://docs.openg2p.org/platform/platform-services/reporting-and-analytics/map-drill-down.md): The choropleth that drills from region to district to ward — where its figures come from, and how a country changes what it shows. - [Setting up reporting](https://docs.openg2p.org/platform/platform-services/reporting-and-analytics/setting-up-reporting.md): What reporting a new deployment gets for free, what to write when it does not fit, and what to do when the country pack or the registry schema later changes. - [Row-level security](https://docs.openg2p.org/platform/platform-services/reporting-and-analytics/row-level-security.md) - [Interoperability](https://docs.openg2p.org/platform/platform-services/interoperability.md): OpenG2P Interoperability - [Notifications](https://docs.openg2p.org/platform/platform-services/notifications.md): How OpenG2P sends notifications. Product services emit business events. The Connector delivers these events to the Notification Provider, which handles notification workflows, channel orchestration, a - [Architecture](https://docs.openg2p.org/platform/platform-services/notifications/architecture.md): Who sends, who delivers, and which identifier the notification provider uses for a staff member and for a registrant. - [Connector](https://docs.openg2p.org/platform/platform-services/notifications/connector.md): The openg2p-notification Python package. send and send\_bulk, environment variables, and how to replace the provider. - [Client](https://docs.openg2p.org/platform/platform-services/notifications/client.md): The @openg2p/notification npm package. It renders the inbox, talks to the notification provider from the browser, and is what the staff UI installs. - [Integrating a new service](https://docs.openg2p.org/platform/platform-services/notifications/integrating.md): How a new application sends a notification from its backend and shows the inbox in its UI. Both sides use the same subscriber id. - [Implementing a send](https://docs.openg2p.org/platform/platform-services/notifications/implementing.md): How a product service sends. After commit, with an allow-listed event key, a payload, and a recipient. - [Workflows and payloads](https://docs.openg2p.org/platform/platform-services/notifications/workflows-and-payloads.md): The 16 notification workflows. Audience, channels, copy, buttons, and the full payload catalog for each event. - [Deployment](https://docs.openg2p.org/platform/platform-services/notifications/deployment.md): Helm values and Docker build args that turn the notification connector on for Registry and AWE. - [Notification provider](https://docs.openg2p.org/platform/platform-services/notifications/notification-provider.md): The system that runs notification workflows, channels, and inbox state. Novu is the default notification provider. - [Novu](https://docs.openg2p.org/platform/platform-services/notifications/notification-provider/novu.md): Default self-hosted Novu 3.19 from the commons chart, workflow seeding, the trigger body the connector sends, and which workflows need email or SMS. - [Creating a New Platform Service](https://docs.openg2p.org/platform/platform-services/creating-a-new-service.md): A prescriptive build guide (and AI prompt) for creating a new OpenG2P platform service the same way as Consent Manager, Partner Management, AWE and G2P Bridge. - [Portals & Apps](https://docs.openg2p.org/platform/portals-and-apps.md) - [Staff Portal](https://docs.openg2p.org/platform/portals-and-apps/staff-portal.md) - [Authentication - Staff Portal](https://docs.openg2p.org/platform/portals-and-apps/staff-portal/authentication-staff-portal.md) - [Developer Install](https://docs.openg2p.org/platform/portals-and-apps/staff-portal/developer-install.md): Developer Installation for Openg2p Staff Portal UI - [Beneficiary Portal](https://docs.openg2p.org/platform/portals-and-apps/beneficiary-portal.md) - [Developer Zone](https://docs.openg2p.org/platform/portals-and-apps/beneficiary-portal/developer-zone.md) - [Developer Setup](https://docs.openg2p.org/platform/portals-and-apps/beneficiary-portal/developer-zone/developer-setup.md) - [Openg2p Beneficiary Portal UI](https://docs.openg2p.org/platform/portals-and-apps/beneficiary-portal/developer-zone/developer-setup/openg2p-beneficiary-portal-ui.md): Developer Installation for Openg2p Beneficiary Portal UI - [Openg2p Portal Server](https://docs.openg2p.org/platform/portals-and-apps/beneficiary-portal/developer-zone/developer-setup/openg2p-portal-server.md): This page provides comprehensive documentation for the installation of Openg2p Portal Server - [React/Next.js Project Structure](https://docs.openg2p.org/platform/portals-and-apps/beneficiary-portal/developer-zone/react-next.js-project-structure.md) - [Deployment of Strapi](https://docs.openg2p.org/platform/portals-and-apps/beneficiary-portal/deployment-of-strapi.md): This guide explains how to deploy Strapi in any environment to enable integration, testing, and production readiness. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openg2p.org/platform.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.