Skip to main content
Veriqa Cloud is the same authentication through messaging apps, run and maintained by someone other than you. Instead of your own server you get a project in the cloud: its own issuer, its own applications, and its own set of enabled channels.
Veriqa Cloud is coming soon. This page already describes the contract of its API. Until the cloud opens, you can run Veriqa on your own server — see the self-hosted quickstart.

​
Concepts

{project} in the addresses is either a slug or a UUID — both are accepted.

​
Who configures what

The split is simple, and it is the main reason the cloud is less work than your own server:
  • the project owner, in the Console: which channels are enabled, the sign-in window branding, the ui_config sets, the confirmation and audit policies;
  • you, the integrator, in your code: issuer, client_id, the secret, and handling the return.
The channel set changes in the Console without touching or redeploying your application. That is exactly why the list of enabled channels should not be hardcoded — see channel buttons on your own page.
There is no public API for managing projects, applications or keys — all of that happens in the Console.

​
Two ways to connect

Redirect — the main path

The user goes to the Veriqa sign-in page and comes back. All you need is an ordinary OIDC client: issuer plus client_id. No Veriqa libraries involved.

Channel buttons on your page

Your page renders the “Sign in with Telegram / WhatsApp / …” buttons. That additionally needs a bootstrap call to learn which channels are enabled right now.
Do not conflate them: they are different amounts of work. If you do not need your own buttons, the whole bootstrap section is safe to skip.

​
How the cloud differs from self-hosted

Beyond who runs it, the API surface differs too: So there are two real differences — introspection and sign-out. When planning a move in either direction, do not assume the two are equivalent here.