Nafath Integration for Saudi Apps: What It Involves

Nafath integration means connecting your app to Saudi Arabia's national unified access service so users can log in by approving a request in the Nafath app. It is not a self-service API key. You need approval for access, and the exact requirements, fees and lead times are not published on any official page we could find, so you must ask in writing.

This guide covers how the login works, who must use it, what to prepare and the mistakes that slow teams down.

What is Nafath and how does the login work?

Nafath is an online service, run by SDAIA's National Information Center, that gives people one secure access point to government and private services. That description comes from the my.gov.sa Nafath service page. Users already know it from government portals.

The user-facing steps on that page are:

1. The user chooses the national unified sign-on in your app or site.
2. They enter their national ID or residency number.
3. A request appears in the Nafath app and they accept it.
4. They match the order number shown in the Nafath app with the one on your screen.
5. They enter their 6-digit personal code.

The number match is a key design point. Your screen must show the number clearly and wait while the user switches to the Nafath app.

Users expect this pattern. The CST Business Portal tells users to log in through the national unified access service (Nafath). The Ministry of Hajj and Umrah vendor registration has a "Login Using Nafath" step.

Who must use Nafath, and who simply benefits?

Only some regulated businesses are required to use Nafath. For everyone else it is a design choice based on how sure you need to be about who the user is.

The SAMA rulebook page says institutions had to complete integration with the approved service provider before 31/01/2023, and that SAMA will take regulatory action for non-compliance. That applies to SAMA-supervised institutions only. It does not make Nafath mandatory for a courier app or an online store.

What access requirements should you expect?

Expect an approval process, not a dashboard. Public detail is thin. The Didit guide reports that fees, the list of attributes you can receive, onboarding lead times and the contract are not published. It advises asking SDAIA or the approved service provider for the requirements in writing.

Other blogs make specific claims, and they disagree:

• A hosting vendor says review takes 7 to 14 business days and that production needs a Saudi-hosted server with a static Saudi IP.
• An agency blog says plan in months and that you generally need a registered local entity and a legitimate use case.

We could not verify any of these against an official page. Treat them as questions to put to the provider, not as facts. A hosting company also has an interest in selling you Saudi servers.

Prepare a pack that answers the likely questions:

• Your commercial registration and legal entity details.
• A clear description of the service and why you need verified identity.
• A privacy policy that explains what you do with national ID numbers.
• A technical contact and a hosting plan, including where your servers sit.

How does the technical flow work?

Most third-party documentation describes a push-and-callback flow. Your server sends a request with the user's ID. It receives a transaction ID and a random number. You show the number to the user. Then you learn the result by webhook callback or by polling the status. The Azakaw API docs describe this for both Saudis and Iqama holders.

One developer blog describes an OIDC-style redirect flow instead. The two descriptions differ, so do not pick a pattern from a blog. Your approved provider's documentation decides.

Signit's help page reports two provider routes: SDAIA, which gives an API key, and ELM, which gives an App ID and key for the app flow and a separate pair for the web redirect flow. Which route you get may depend on your approval. Ask which applies to you.

Design for these states from day one:

• Pending: the user has not yet opened the Nafath app.
• Accepted: the request was approved and your callback arrives.
• Rejected or expired: the user declined or took too long.
• Provider error: the service is unavailable, so show a clear message and a retry.

What does Nafath integration involve, step by step?

A realistic plan runs in this order. The access step comes first because it is the one you cannot control.

1. Decide why you need it. Verified login, account recovery, contract signing or a regulated onboarding step each need different assurance.
2. Contact the provider early. Ask SDAIA or the approved service provider for requirements, fees, attributes, contract terms and timelines in writing.
3. Choose your route. Confirm whether you get an API key, an app-flow ID, a web-redirect ID, or all of them.
4. Build against a mock. Create the screens, states and webhook handler. A mock is not production approval.
5. Wire up the real service. Use only endpoints and credentials the provider gives you. Never guess endpoints.
6. Add a second login option. Offer email or phone login for people without a Saudi ID or Iqama, unless a regulation requires Nafath only.
7. Test failure paths. Expired requests, wrong ID numbers, duplicate taps and webhook retries.
8. Review data handling. Log as little as the approval allows.

A short hypothetical: say a Jeddah courier platform wants to verify its drivers before assigning cash-on-delivery runs. Nafath confirms that the person holding the ID approved the login. It does not tell you whether the driver has the right permits or a clean record. You would still need your own document checks after the Nafath step.

What are the common mistakes?

• Treating Nafath as full KYC. One comparison article reports that Nafath is mainly authentication and consent, not full verification of ID data. Yakeen by Elm is a separate service that the SAMA rulebook references for ID data. Check with the provider which attributes you can receive.
• Starting the build before asking about access. If approval takes months, your launch date moves with it.
• Making Nafath the only login. Overseas buyers, suppliers and new investors may have no ID or Iqama.
• Logging too much. Do not store national IDs, biometric data, tokens or secrets beyond the approved minimum. Treat ID numbers as personal data under Saudi PDPL and confirm your obligations with your legal adviser.
• Copying numbers from blogs. Review times, IP rules and fees quoted online conflict. Use them as a list of questions.
• Forgetting the user's side. Guides say the user's mobile number must be linked to Absher and that the app is on the App Store, Google Play and Huawei AppGallery. These are from non-official guides, so confirm on iam.gov.sa before you write help text.

Where does an app developer fit in?

Approval is between your business and the provider. No developer can skip it for you. What a developer can do is scope the integration, build the screens and callbacks, and keep identity data out of logs. If you are planning an app, Quickship builds mobile apps and custom software on quote. See app development or custom software. Quickship is a technology company and does not issue or approve Nafath access.

Bring the provider's written answers to any scoping call. They decide the timeline, the cost and the data you can use.