You need this path only if you render the “Sign in with Telegram / WhatsApp / …” buttons
yourself instead of sending the user to the Veriqa sign-in page. No buttons of your own means
no need for this page — the ordinary connection is enough.
Why bootstrap exists
The set of enabled channels is decided by the project owner in the Console and can change at any
time. A list hardcoded in your code turns into a dead button: the channel is switched off, the
user taps it, and nothing works until your next deploy.
bootstrap is a single GET at application start that fetches the current project
configuration instead of keeping it in your own config. It is a Veriqa extension, not a standard
OIDC endpoint.
Without the cloud key the response carries public fields only. The response is the effective
configuration for that specific client_id — the project’s values narrowed by the application —
not a dump of project settings.
What comes back
Two of these fields do the work; the rest are conveniences:
channels_enabled — the reason the mechanism exists: exactly the set of buttons to show
right now;feature_flags — what tells you whether to surface step-up, channel linking and operation
confirmation in your own interface.
The endpoint addresses duplicate discovery and save one request at startup. ttl_seconds is how
long the response may be cached, 300 seconds by default; after that, fetch it again.
The stable fields of the contract are channels_enabled and feature_flags. Build your logic
on them, and do not tie code you would hate to rewrite to the other fields.Numeric limits, if the response carries them, are informational: not a commitment, and not a
replacement for the protection running on the cloud side.
There is no branding in the response. The project name, logo, color and theme are applied by
the server when it renders the sign-in page — the integrator does not need them, and they
are not part of the contract.
Behavior on failure
What bootstrap does not guarantee
The bootstrap response is not a promise of what the user will see. The authoritative
resolution happens on the server at /connect/authorize: a ui_config or acr_values you pass,
along with per-user overrides, can produce a different result.
