Digitalizing Government Services: Integrating with ЕПИГУ and State Systems

What ЕПИГУ is and why connect to it

ЕПИГУ — the Unified Portal of Interactive Government Services (my.gov.uz) — is the storefront through which citizens and businesses receive hundreds of government services electronically. For a government body, bank, telecom operator, or private company, connecting to the portal means one thing: your service becomes available to millions of users through a single entry point, with identification, payment, and result delivery already working out of the box.

But ЕПИГУ is not just a website. It is part of a broader e-government infrastructure that includes the inter-agency electronic exchange system, the state personalization database, registries of the population and legal entities, and digital signature mechanisms. When a client says "we need integration with ЕПИГУ," in practice it almost always means wiring together several state systems at once.

Inter-agency exchange: how data moves between systems

The core idea of a digital state is that a citizen should not carry paper certificates from one agency to another. Instead, systems exchange data directly. In Uzbekistan this role is played by the inter-agency exchange infrastructure, which works like a message bus: each agency publishes its services (for example, residence verification, taxpayer status, or outstanding debt checks), and other participants call them according to an agreed protocol.

In practice this means your system never queries another agency's database directly. The request travels through a centralized gateway that checks access rights, logs the call, and returns the response in a standard format. Each exchange is formalized by a separate agreement and technical regulation — you cannot simply "get access to all the registries."

• User identification — through the single sign-on system (OneID), which provides verified data about an individual or legal entity.
• Reference data retrieval — address, family composition, sole proprietor/LLC registration, tax status — via specific services of specific agencies.
• Confirming legally significant actions — through digital signatures and state key centers.
• Accepting payments — through integrated payment gateways and the state treasury.

Connection requirements

Connecting to state systems is first and foremost a legal and organizational process, and only secondarily a technical one. Before writing a single line of code, you need to understand the set of requirements.

A typical list of requirements includes:

• a legal basis for processing the requested data (a law, a resolution, a contract);
• a secured communication channel — access is usually granted into a closed network segment, not over the open internet;
• an accredited electronic signature for signing requests and legally significant documents;
• compliance with personal data protection rules and storage of that data within Uzbekistan;
• passing testing in a sandbox environment before production access is issued.

The integration stages in practice

Across several projects we have developed a sequence that reduces the risk of getting stuck in approvals.

1. Analysis and service mapping. We define exactly which services are needed: what data we read, what we write, which actions must be legally significant. This is where it becomes clear how many agencies you will actually have to deal with.

2. Legal formalization of access. Signing agreements with system operators, describing the purposes of data processing, agreeing on protocols. This is the least predictable stage by timeline, and you should budget weeks for it, not days.

3. Obtaining test access. Sandbox credentials, test certificates, API documentation. Exchange formats in state systems are most often based on SOAP/XML described in WSDL, less often REST; legacy schemas also appear, so there is no universal connector.

4. Development and testing. Implementing connectors, signing requests with the digital signature, handling errors and timeouts, maintaining a request log. From the very start it is important to design the system as if the external service might respond slowly or not respond at all.

5. Acceptance testing and production access. Demonstrating to the operator that the integration works according to the protocol, after which live credentials are issued.

Security and data protection

Working with state registries means handling the sensitive personal data of millions of people, so security requirements here are stricter than in an ordinary commercial project.

• Data storage in Uzbekistan. Citizens' personal data must be stored on servers inside the country — a direct legal requirement that affects your hosting and architecture choices.
• Minimization. Request and store only the data genuinely needed for the service. Every extra field is a risk and one more thing to negotiate.
• Logging. All calls to state services must be logged: who requested what, when, and on what basis. This is both a regulatory requirement and your protection during incident investigations.
• Channel and key protection. A closed network segment, encryption, secure storage of digital signature private keys, and access rotation.
• Access control inside the system. An employee of your organization should not have the technical ability to export an entire registry — access is limited by roles and the context of a specific operation.