e-Devlet, the incumbent answer in Türkiye, and why we say so on our own page

Solidus has no e-Devlet integration, and no Solidus credential derives from or is co-signed by an e-Devlet authentication event. The term is not-built in our lexicon.

This page names a competitor that is better than us at something, because a Turkish business evaluating identity verification is going to ask the question anyway, and the answer is better coming from us.

What it is

e-Devlet Kapısı, the e-Government Gateway, is Türkiye's unified public-services portal, live since December 2008 and operated by TÜRKSAT on behalf of the Presidency's Digital Transformation Office. One login reaches several thousand government services.

A person authenticates with a TCKN plus an e-Devlet password, a mobile signature, an electronic signature, or the mobile app's biometric login.

The part that matters commercially: because that login is itself an identity confirmation tied directly to the national population registry, private businesses, banks, telecom operators, and since the 2025 rules, crypto-asset service providers, routinely use "confirm this via e-Devlet" as a step inside their own onboarding. It stopped being only a citizen-to-government portal a long time ago.

What it does better than us, stated without hedging

It is authoritative. It resolves against the population register itself. Our pipeline reads a document and checks a face; it does not, and cannot, consult the register.
Essentially every Turkish adult already has it. There is no enrolment step, no wallet to install, no credential to issue first. That removes the precondition our whole argument depends on.
It is free at the point of use for the citizen, and familiar enough that it adds almost no friction to a Turkish onboarding flow.

For a Turkish business onboarding Turkish citizens for a domestic service, that is a strong position, and we are not going to argue otherwise.

What it does not do

It is an authentication event, not a portable credential. It proves someone logged in, at a moment, at a gateway. The person walks away holding nothing they can present again somewhere else.
It is for Turkish citizens and residents in the Turkish register. A business onboarding customers from outside that register gets nothing from it.
It is all-or-nothing at the point of check. There is no mechanism for proving one attribute, over 18, resident, while withholding the identifier that joins you to every other record.
Every check is an online event at a central gateway. Availability, and the record of the check, sit with that gateway rather than with the person.

Those are architectural differences, not deficiencies. e-Devlet was built to be a government gateway and it is an excellent one. It was not built to make a verification travel between two private companies, which is the thing we are trying to build.

The honest read for a Turkish buyer

If your customers are Turkish citizens, your service is domestic, and your requirement is a registry-backed identity confirmation, e-Devlet, and the vendors already integrated with it, are the shorter path. Our pipeline does not meet MASAK's registry-match requirement on its own.

Where our argument has something to say is the case e-Devlet does not cover: a customer outside the Turkish register, a verification you want to be reusable at a second business, or a check where you would rather receive an attribute than the identifier behind it. That is a narrower case than our marketing would like it to be, and it is the honest one.

And we cannot integrate unilaterally

An e-Devlet-adjacent verification path is identified internally as something the Turkish market needs. There is no integration and no agreement, and this is not a matter of engineering effort: access is granted by the operator and the responsible authority, not taken by a vendor. We cannot grant ourselves that status, exactly as we cannot grant ourselves a licence. Treat it as absent.