An engineer’s guide to Saudi government platform integrations: Nafath, Absher, Wathq, Ejar, Sakani — what repeats in every project

Every serious product in Saudi Arabia reaches the same moment: “we need to integrate with Nafath”. Then Wathq for commercial registrations, Ejar for contracts, then Sakani, Absher or Muqeem depending on the sector. We have done it for property, booking, e-signature and HR platforms, and this is what repeats regardless of the platform.

The map: who does what

• Nafath: unified national authentication — “log in with your identity”. Gives you a verified identity and basic data.
• Absher / Yakeen: verifying and matching individuals’ data (ID, date of birth).
• Wathq: commercial registration and establishment data — who owns and who represents the company.
• Ejar: documenting residential and commercial tenancy contracts.
• Sakani: the housing portal — projects, units and support.
• Muqeem / Musaned: resident and workforce data — for HR and payroll systems.
• Fatoora (ZATCA): e-invoicing — for anyone who sells.

Rule 1: onboarding is the real project

The code takes two weeks; getting approvals, certificates, the test environment and signatures takes two months. Start the paperwork the day the contract is signed, not the day the UI is done.

Rule 2: one abstraction layer per authority

An internal module called Identity with Nafath behind it, a Business module with Wathq behind it, a Tenancy module with Ejar behind it. Business logic talks to our modules, not to the authorities’ APIs. When an authority changes its interface (and it will), one file changes.

Never let the word “Nafath” appear in more than one folder of your repository.

Rule 3: every call has a log and a reason

Government bodies ask: why did you query this person? Record who asked, for which operation, when, and the result — before you are asked. That is also what makes PDPL compliance real rather than paper.

Rule 4: design for outages and slowness

• Explicit timeouts and retries with exponential backoff.
• A human fallback path: “verification unavailable right now — we will complete it within an hour and notify you”.
• Never block the customer’s whole flow on a secondary lookup; make verification asynchronous where possible.

Rule 5: the simulator first

For every integration we build a local simulator returning the same shapes and errors we saw in production. The team develops and tests without depending on the authority’s environment being up, and automated tests include the real failure cases (expired certificate, unknown number, timeout).

Patterns by sector

• Real estate: Nafath + Ejar (+ Sakani for subsidies). Tenant and owner verified and the contract documented before any payment.
• HR and payroll: Muqeem/Musaned + Wage Protection. In our payroll systems the WPS file is generated from the approved payroll run, not from a manual Excel file.
• E-signature: Nafath for identity + timestamp + audit trail — as in Tawqe3k.
• Commerce: Wathq to verify the merchant + Fatoora for invoicing.

Takeaway for the decision maker

Government integrations are not a feature added at the end; they decide whether your product gets approved at all. Start early, isolate them architecturally, log everything, and build the simulator before the UI. The difference between a project launched on time and one delayed by half a year is usually this chapter.