The technical work of integrating with a Saudi government platform is a few weeks of ordinary OAuth-shaped engineering. Getting permission to do it is the part that takes months. These are not open APIs with a developer signup — access requires a registered local entity, a legitimate and stated use case, and an approval process with the authority that operates the platform. Some services are restricted by sector.
If you are scoping a project that depends on Nafath, Absher, Yakeen or Wathq, the integration is not the risk. The access timeline is, and it belongs in the plan as a dependency with its own start date — not as a task inside the sprint where you build the screen.
Engineering context. Eligibility for any of these platforms is determined by its operator, not by us.
The landscape, and what each thing actually is
These names get used interchangeably in project documents by people who have not integrated with them. They are different systems doing different jobs.
Nafath is the national single sign-on and authentication layer — the front door. A user proves who they are through the Nafath app or portal, and your application receives a verified identity. It is the login, not the data source. We cover it in detail in our Nafath integration guide.
Absher is the Ministry of Interior services platform, delivered in three channels: Absher Individuals, Absher Business and Absher Government. It is a destination — where citizens and residents transact with the Ministry — and it has passed 28 million digital identities. Absher Business is the channel through which establishments handle their MOI-related dealings.
Yakeen is an identity verification service operated by Elm. It verifies personal data for citizens, residents and visitors against an official ID, Iqama or visa number. Where Nafath answers "is this person who they claim to be, right now", Yakeen answers "do these details correspond to a real, valid record".
Wathq provides commercial and business data, including access to the Council of Saudi Chambers records. It is how you verify that a company is real, active, and represented by the person signing your contract.
Etimad is the Ministry of Finance government tenders and procurement platform — the gateway for financial dealings with government entities. Industrial and energy supply chains have their own parallel to this in Aramco's iktva programme, covered in building industrial software in the Eastern Province.
Alongside these sit the operational platforms: Qiwa for labour contracts, Mudad for payroll and wage protection, GOSI for social insurance, SADAD for payments and ZATCA for e-invoicing. Open banking is a separate, now-licensed regime — see SAMA open banking licensing. The HR and payroll group is its own problem, covered in Qiwa, Mudad, GOSI and WPS.
Choose by the question you are answering
Most integration mistakes at design time come from picking a platform by reputation rather than by the question in the user flow.
- "Let this person log in without a password, with government-grade assurance." → Nafath
- "Confirm this ID number belongs to a real, valid person with these details." → Yakeen
- "Confirm this company exists and this person can act for it." → Wathq
- "Let an establishment conduct its Ministry of Interior business." → Absher Business
- "Bid for, or transact against, government contracts." → Etimad
A surprising number of requirements that arrive as "integrate with Absher" are actually answered by Nafath (a login) or Yakeen (a check). Establishing which one you need, early, saves an approval cycle you did not have to spend.
Plan access as a dependency, not a task
The honest planning advice, and the reason this article exists: approval is an application process with the operating authority, not a developer signup. Expect it to need a registered local entity and a documented use case, and expect some services to be restricted by sector — a fintech, a healthcare provider and a logistics company do not get the same access to the same data.
Plan in months rather than weeks. That is a planning heuristic drawn from how these processes work in practice, not a published service-level commitment — timelines vary by platform, by applicant and by use case, and the operator is the only authority on what yours will be.
What this means for a delivery plan:
Start the access process before the build, not with it. The application often needs things that take their own time to assemble: the local entity, a commercial registration, a described data flow, security undertakings, sometimes a named responsible officer.
Design the application so it can be built and demonstrated without live access. An interface behind which a stub sits, swapped for the real client when credentials arrive. This is ordinary good practice and it is close to mandatory here, because the alternative is a team sitting idle waiting on a letter.
Do not let a demo depend on it. If a milestone demonstration needs verified identity, use the stub and say so plainly to the client. A missed demo because an authority has not yet responded is avoidable and reflects on delivery rather than on the authority.
Put the dependency in the contract. Where a fixed-price scope assumes access to a government platform, name it as a client-side or shared dependency with an explicit assumption about timing. This is not defensive paperwork — it is the single most common cause of a Saudi project slipping, and both sides benefit from it being visible on day one.
What the integration itself looks like
Once access exists, the work is recognisable. Expect:
- OAuth-style authorisation flows and, in the more sensitive services, mutual TLS with client certificates. Certificate lifecycle — issuance, storage, renewal, rotation — is real work and tends to be under-scoped.
- A sandbox that is not the production data. Test identities behave differently from real ones; budget for surprises at the cutover.
- Response shapes that assume Arabic. Names, addresses and titles arrive in Arabic, sometimes only in Arabic. If your data model or UI cannot hold them properly, that surfaces here.
- Sensitive data on the wire. National IDs, Iqama numbers, personal attributes. Whatever you receive falls under Saudi data protection obligations, so retention, access control and logging need deciding before the first call — see Saudi PDPL for application architecture and, for where that data may physically live, Saudi cloud data residency.
Store as little as you can. The strongest position after a verification call is to keep the result and not the payload: this identity was verified at this time by this service. Keeping the full record because it might be useful converts a verification integration into a personal-data repository, with everything that entails.
Frequently asked questions
Can I sign up for these APIs as a developer and start building?
No. Access is granted through an application to the operating authority and generally requires a registered local entity and a legitimate, stated use case. Some services restrict access by sector.
What is the difference between Nafath and Absher?
Nafath is the national authentication layer — the login. Absher is a Ministry of Interior services platform reached behind it. They are not substitutes.
When should I use Yakeen instead of Nafath?
Nafath when you need the person to authenticate themselves. Yakeen when you need to verify that submitted identity details match an official record.
Do I need a Saudi entity?
Expect one. Eligibility generally requires a registered local entity, and the operator decides. Confirm your specific position with the platform before committing to a delivery date.
How long does approval take?
Plan in months rather than weeks, and treat any estimate — including that one — as a planning assumption rather than a commitment. Only the operating authority can tell you.
Can we build while the approval is pending?
Yes, and you should. Put the integration behind an interface with a stub implementation and swap it when credentials arrive.
Is Wathq the right way to verify a company?
It is the platform for commercial and business data, including Council of Saudi Chambers records. Whether it fits your specific verification need is a question for the platform's documentation and your use case.
What are Qiwa, Mudad and GOSI?
Labour contracts, payroll and wage protection, and social insurance respectively — the employment stack rather than the identity stack.