On this page
Getting started
The Pamodzi Developer Hub is the place to learn, build on and get access to the Pamodzi e-Services framework: the Government of the Republic of Zambia's platform for delivering public e-services through one national portal and the back offices of the ministries, departments and agencies (MDAs) that own them.
This page explains what the hub offers, how to sign in, how to complete your profile and where to start.
What the hub offers
| Area | Address | What you find there | Sign-in needed |
|---|---|---|---|
| Guides | /docs | How the platform works: architecture, integration, identity, payments, federation, modules, registers, testing and security | No |
| API reference | /apis | The specifications of the platform's APIs, taken from the platform repositories | No |
| Service catalogue | /services | Every e-service on the platform, with its owning MDA and the evidence from its end-to-end test: the five checks, the generated service documentation and screenshots | No |
| Training | /training | Self-paced courses with a final assessment and a certificate | Yes, to record progress and take an assessment |
| Access requests | /access | Ask for data from a national register, a Partner API client, or to join the federation as an MDA node | Yes |
Guides, the API reference and the service catalogue are public. You sign in when you want the hub to remember something about you: your lesson progress, your certificates and your access requests.
The API specifications, the register catalogue and the service status list are copied from the platform repositories by the hub's sync job. They are never edited by hand on the hub, so they say what the software does.
Sign in
The hub does not keep passwords. You sign in with a national identity provider:
- Pamodzi Pass, the national single sign-on that is being built to replace ZamPass. Its protocol core, accounts,
second factor and account pages are written; the bridge from ZamPass and the switch-over of the e-Services platform are still to come.
- ZamPass, the existing government OAuth / OpenID Connect server.
The sign-in page shows only the providers that are configured for this hub.
Both are used the same way: OpenID Connect with the authorization code flow, PKCE and a nonce. The sign-in is bound to the browser that started it, so a callback address cannot be replayed from somewhere else. The hub validates the ID token it receives (signature, issuer, audience, expiry and nonce) before it trusts anything in it.
What the hub asks for and keeps:
| Item | Kept by the hub |
|---|---|
| Your name, e-mail address and, from Pamodzi Pass, your phone number | Yes, so it can address you and write to you about requests and certificates |
| Whether the identity provider said your NRC is verified | Yes, as a yes/no flag only |
| Your NRC number | Never |
| Your password, tokens from the identity provider | Never |
A hub session lasts at most 8 hours and ends after an hour without activity (the default settings). Signing out ends the session on the hub.
Complete your profile
After your first sign-in the hub asks you to complete a short profile. It is required before you can use training or access requests.
| Field | Why it is asked |
|---|---|
| First and last name | Printed on your certificates |
| E-mail address | Updates on your access requests and certificates. If you change it, it counts as unverified until your identity provider confirms it |
| What describes you best | Government (an MDA), developer or integrator, vendor, student or trainer, or other. It decides which courses are suggested |
| Organisation | The organisation you work for, or "Independent" |
| MDA code | Government staff only, for example MOH. Reviewers of access requests for your MDA use it |
| Job title, experience, interests | Optional. They help the hub suggest courses |
| Terms of use | Must be accepted |
| Contact | Optional consent to be told about new courses and platform changes |
Your profile never gives you a hub role. The roles that handle other people's requests (reviewer, data steward, administrator) are granted by a hub administrator, and an administrator cannot change their own roles.
Which course to take first
Every course is self-paced. You open a course's assessment when you have completed all its lessons and hold a valid certificate for each prerequisite course. An attempt draws 10 questions at random from the course's question bank; you pass with 80 %. By default you may start 3 attempts per course per day, and an attempt expires after an hour. Certificates carry a public verification code and an expiry date, and an administrator can revoke one.
| You are | Start with | Then |
|---|---|---|
| Anyone new to the platform: MDA staff, managers, developers, vendors | Pamodzi e-Services Foundations | The course for your role below |
| An MDA officer or data custodian who handles personal data or register access | Pamodzi e-Services Foundations | Data protection and registers |
| An MDA officer who designs services in the back office | Pamodzi e-Services Foundations | Service designer |
| A developer integrating another system through the APIs | Pamodzi e-Services Foundations | The integration developer course in the training catalogue |
| A developer building a ministry module | Pamodzi e-Services Foundations | Module developer |
| A developer or tester who proves services end to end | Pamodzi e-Services Foundations | End-to-end testing and documentation |
| MDA ICT staff who will run their own back office as a federation node | Pamodzi e-Services Foundations | Federation operator |
| Anyone who will ask for register data | Pamodzi e-Services Foundations | Data protection and registers, which is required (below) |
Some access requests need a certificate first:
| Access request | Certificate needed |
|---|---|
| Data from a national register | Pamodzi Certified Data Steward (course data-protection-registers) |
| Partner API client for the test environment | None |
| Partner API client for production | The integration developer certificate (course integration-developer) |
| Join the federation as an MDA node | The federation operator certificate (course federation-operator) |
Ask for access
The hub's access request page is the intake for access, not the place where access is created:
- You describe what you need, for which organisation, the purpose, the legal basis, the data items, the volume, how
long you will keep the data and your safeguards.
- A reviewer checks the request and either asks you for more information or recommends a decision.
- A data steward, who is never the person who recommended it, approves or rejects it. Nobody handles their own
request.
- When it is approved, the owning MDA issues the real access on the platform itself: a data-sharing agreement for
register data, or a Partner API client. The steward then records that reference on your request, which becomes "Access issued".
The hub never issues credentials or grants. See Registers and data sharing for how the platform issues them.
Next steps
- Read the platform overview and the architecture.
- Read Security and data protection before you write any integration.
- Browse the service catalogue to see what a fully tested service looks like.