Skip to main content
The main path is an ordinary redirect: the user goes to the Veriqa sign-in page and returns to your application. From your code’s point of view this is a standard OIDC client — the same one you would set up for any provider.

​
What you need

  • the project address: https://<cloud host>/p/{project};
  • the application’s client_id and, if it is confidential, its client_secret;
  • a redirect_uri registered in the Console.
Veriqa libraries are not required. Neither is any preliminary request for configuration: everything the client needs is in the discovery document.
bootstrap plays no part on this path. It is only needed when your own page renders the channel buttons — see channel buttons.

​
The five addresses that are enough

Point your library at the issuer — it will take the rest from discovery. Spell the addresses out by hand only where the client cannot do discovery.

​
Authenticating requests

The cloud endpoints beyond OIDC use the X-Veriqa-Cloud-Key header, described on the channel buttons page.

​
Parameters /connect/authorize understands

Besides the standard scope, state, nonce and PKCE:
  • acr_values=channel:<type> — narrow the channels down to the ones listed (separate multiple values with a space);
  • ui_locales — the language of the sign-in window;
  • ui_config — the code of a settings bundle created by the project owner; see the customization section.

​
Checking things on the spot

GET /p/{project}/v1/status returns the project and channel status, and GET /v1/health the health of the cloud instance. Both are public, which makes them handy for monitoring and for quickly answering “is it me or the cloud”.
Addresses like https://cloud.veriqa.io/... in examples are illustrative. Your cloud’s actual host is shown in the Console.