UAE Pass integration: the approval is the hard part

UAE Pass publishes a working sandbox client ID and secret in its own documentation — sandbox_stage / sandbox_stage, with "any preferred URL" accepted as the callback. Anyone, anywhere, can complete a full authorization-code round trip this afternoon. That is why UAE Pass integration is almost never a protocol problem. It is an eligibility and approval problem with a short technical tail, and the calendar it eats belongs in the project plan, not the sprint backlog.

We have not delivered a UAE Pass integration ourselves. Creuto has no first-hand UAE delivery record, and this post is a close reading of the public rules on docs.uaepass.ae as they stood in October 2026 — not a report from a project. Where the official documentation contradicts the agency guides that dominate search results for this topic, we say so and name both.

What UAE Pass integration actually involves: four phases, not one sprint

The official onboarding guide breaks service provider onboarding into four phases: Initiation, Development, Assessment and Go live. Only one of those four is mostly engineering. Here is what each one actually asks of you.

Phase	What you produce	What gates the exit
Initiation	Portal request stating entity type; valid UAE trade licence (private entities); feature questionnaires; use-case workflow diagram; UI wireframes	Onboarding team evaluates and approves the use case
Development	Staging integration against credentials the onboarding team issues	You tell them you are done and request the staging assessment
Assessment	A live assessment session, fixes, a second round if needed, and video recordings of every scenario tested	Onboarding team lead reviews the videos and the use-case details and approves go-live; private service providers finish signing the Service Provider Agreement
Go live	Go-live form, production implementation, a production assessment	Production credentials issued, service desk credentials handed over

Read that table as a calendar rather than a checklist. Three of the four phases are gated by somebody else's review queue. The one you control is the one teams budget for.

The OAuth part is a day's work, and the docs hand you a sandbox to prove it

The published endpoints are four per environment — authorize, token, userinfo, logout — at stg-id.uaepass.ae/idshub/ for staging and id.uaepass.ae/idshub/ for production. If you have shipped a social login, you have shipped this shape of thing. The authorization code is single-use and expires in 10 minutes; the access token lives 3,600 seconds in production and the duration is not configurable per service provider, which the FAQ states plainly.

The important practical fact is that the shared proof-of-concept credentials are not gated behind onboarding. The documentation says they work only on staging and that separate staging credentials will be issued to your entity during onboarding — but they are enough to build and demonstrate the full flow. The staging environment is open from anywhere, too: the guide notes that staging accounts "can be created in staging from any location as there are no restrictions from UAE PASS end", and the FAQ says production and staging APIs are both accessible from overseas.

So before approval you can build the whole authentication path, the account-linking logic, the error handling and the login button, and you can run a demo for a stakeholder. What you cannot do is point it at a real user base. Production credentials arrive in phase four, after a signed agreement and two assessments.

Do I need a trade licence for UAE Pass?

If you are a private entity, yes. Step 2 of the Initiation Phase is the onboarding team acknowledging your request and requesting "valid UAE Trade license for private entities", and the emirate you are registered in determines which onboarding team handles you. There is no documented path for a company with no UAE registration to become a service provider in its own name.

This is the single most expensive thing to discover late. A fixed-price build that reaches week six before anyone asks who holds the trade licence has a commercial problem, not an engineering one — and the fix is a company formation timeline, which no amount of overtime compresses. Put the licence question in the first discovery call, before the estimate.

What the onboarding team asks for before you get staging credentials

The questionnaires are per feature, not per application: Authentication, Digital Signature, e-Seal (plus an e-Seal certificate request form), Hash Signing and Data Sharing Authorization each have their own. Alongside them you submit a workflow diagram of the UAE Pass user journey and UI mockups of it.

The Use-Case Guidelines explain why: you are expected to pick a numbered standard scenario (UC X.X.X) from their catalogue and cite the number on your diagram. Deviate from it and the documentation warns that the use case "will necessitate approval from management" and that "obtaining this approval may extend the overall processing time". The guidelines also confirm the ordering that catches people out — staging credentials are shared after the use case is approved, not before.

Two details in the Standard Implementation Guidelines reshape scope rather than code. Client credentials are channel-specific: a web approval does not cover your mobile app, and reusing credentials across a channel or use case requires discussion and approval. And automatic linking, manual linking and new-user registration must all ship "in the same release for go-live" — you cannot land the easy linking path first and follow up next quarter.

Four implementation rules that fail integrations at assessment

The same guidelines list what the onboarding team checks before use-case sign-off, at staging assessment, immediately after go-live and in quality assurance. Four of them are product decisions a backend team would not think to ask about:

• The UAE Pass flow must be fully segregated from your local login. "Sign in with UAE Pass" may never be merged into your existing local login or registration flow.
• You may not give the user a local password. During registration via UAE Pass you can create a backend account with a temporary password, but the user must not be prompted to set credentials and the local user ID and password must not be sent to them by email or SMS during or after registration.
• The UUID is the linking key and must be stored. Account linking is a one-time step on first login, and subsequent sign-ins must match on the UUID UAE Pass returns.
• Partial adoption is discouraged. The guidelines say UAE Pass is intended for authentication and the full journey must be implemented, giving the example that using UAE Pass only to update a user's email or mobile number "should be avoided".

None of these is hard to build. All of them are expensive to retrofit after a design review, which is exactly where they surface if nobody read the guidelines during estimation.

How long does UAE Pass approval take?

The official documentation publishes no timeline. As of October 2026 there is no stated approval SLA anywhere on docs.uaepass.ae — the FAQ answers the SLA question by pointing you at your MoU if you are a government entity or your Service Provider Agreement if you are private. The widely repeated "two to six weeks" figure is not in the official docs, and it is not in the agency guides that rank for this query either: the Pixbit developer guide describes the approval reviews without giving any duration. We cut the number rather than repeat it.

What the documentation does tell you is which steps have unbounded duration, and that is more useful for planning:

• Use-case approval in Initiation, which goes to management if your flow is non-standard.
• The assessment session, which the process explicitly allows to run twice.
• Management review of your scenario recordings before go-live is approved.
• Service Provider Agreement signing, which private entities must complete before the go-live step.
• For e-Seal, a separate certificate process outside UAE Pass entirely.

That last one deserves its own warning. e-Seal splits by emirate: Dubai entities go through DESC as the certificate authority, while non-Dubai entities go through a 12-step ICP process — an account on the ICP registration authority portal, a certificate holder agreement, vetting that checks the signatory holds a general power of attorney, and a certificate signing request passed between ICP and the UAE Pass operations team. Hash signing adds an IP whitelisting step at DESC for production. If your plan treats e-signature as a sprint item alongside login, it is wrong by a wide margin.

Our reading — and it is a reading, not a documented rule — is that government and semi-government applicants move faster because they have structurally fewer gates: an MoU instead of a Service Provider Agreement, and no trade licence step at all. The documentation does not say this, so treat it as inference.

What you get for the work, and when it is not worth it

Three things justify the effort. First, verified identity you did not have to build: an SOP2 or SOP3 account returns a verified Emirates ID number, full name in English and Arabic, nationality and gender, where an SOP1 basic account returns only a verified email, mobile, given name and the UUID. Second, e-signature at a legal grade you cannot approximate — advanced signatures at SOP2, qualified at SOP3, in PAdES for PDFs, CAdES for binary and XAdES for XML. Third, and most underrated, your users already have it. TDRA's digital government portal reports 15,000+ services, 363 service providers and over 11 million registered users on UAE Pass across government, semi-government and private sector entities.

If you are building anything that currently asks a UAE resident to photograph an Emirates ID and wait for a human to check it, UAE Pass replaces a queue with a redirect. That is also why it is worth reading alongside the identity-assurance obligations now appearing in UAE law — our note on why "enter your birthday" no longer counts as age verification covers a case where verified attributes stop being a nice-to-have.

Now the honest counter-case, in its strongest form. UAE Pass is the wrong choice when your user base is not primarily in the UAE, because you still have to build and maintain a second authentication path for everyone else and you have added a gated dependency to your release process for no coverage gain. It is the wrong choice when a verified email is all your product needs, because any OAuth provider gives you that without the onboarding. It is the wrong choice for a narrow feature, both because the guidelines discourage limited-scope use and because the fixed cost of approval does not amortise over one screen. And it is the wrong choice on a fixed-price contract signed before anyone confirmed who holds the trade licence.

Is the UAE Pass API open?

Both answers in circulation are half right, and the distinction matters for how you plan. The FAQ states that "UAE PASS APIs are public; production and Staging APIs are accessible from overseas", and the shared sandbox credentials back that up — nothing stops you reading the spec and exercising staging. But production access runs through entity eligibility, a signed agreement and a per-channel approved use case, so in the sense a developer usually means by "open API" — self-serve credentials, instant production access — it is not one. The protocol is open; the production relationship is a procurement process.

One more thing to verify rather than assume: the FAQ says there are currently no charges for integrating with UAE Pass, but qualifies it with "A review shall be done in 2021", so the statement is at least five years stale as of October 2026. Confirm commercial terms with the onboarding team, not with the documentation. Note too that while reported coverage commonly calls UAE Pass an OpenID Connect provider, the official guides describe it as OAuth 2.0 throughout; OpenID Connect appears once, in the mobile WebView guidance, and the openid scope does return an ID token. Build to the documented OAuth 2.0 flows and treat OIDC conveniences as something to confirm per endpoint.

What a project plan should assume

Treat the integration as two tracks that start on day one and converge late. The administrative track — trade licence confirmation, portal request, questionnaires, use-case diagram against a numbered standard scenario, wireframes — has no engineering dependency and should begin before the first sprint. The engineering track can run against the public sandbox in parallel and should deliver all three linking scenarios in a single release, because go-live requires it.

The two converge at the assessment session, and that is the date to protect. Plan for two assessment rounds rather than one, record your scenarios as you test them because you will have to hand over the videos, and do not let any production go-live date be communicated to a client until production credentials are actually in hand. If you want this scoped by a team that will read the guidelines before quoting, our API development and integrations practice does this kind of gated third-party work, and you can see how we engage with clients building in Dubai — including the fact that our delivery record is elsewhere. For a wider view of how UAE regulators are now specifying implementation rather than outcomes, the same pattern shows up in the Dubai agentic AI mandate.

The decision this post is meant to change is a scheduling one. If UAE Pass is in scope, the first ticket is not "spike the OAuth flow" — it is "confirm which legal entity holds the trade licence and submit the use case". Everything else can wait for that answer; nothing can ship without it.