Settings
Your organization, your own account security, and the rules that apply across every flow
Settings holds three different kinds of thing: facts about your organization, security for your own account, and account-wide rules that every flow inherits. Which of them you can change depends on your role, and the ones you cannot are shown but disabled rather than hidden.
Organization
Your name, your organization id, your slug, your engine tier and when the account was created. The organization id is what our support team will ask you for.
Environment
A line telling you which environments your seat can open, and where the toggle is. If it says your access is limited to sandbox, an owner grants live from the Team page.
Branding and white-label
Your accent colour, and the custom domain that hosts the verification flow. Leave the domain blank and applicants use our hosted page.
These are the fallbacks. Any individual flow can override them, which is what you want when one flow belongs to a differently branded part of the business. Anything a flow leaves blank falls back to here.
Security and your account
Every member of your organization uses an authenticator app. It is set up on first sign-in and cannot be turned off, because the console is where your applicants' identity records live.
Two-factor authentication shows whether yours is enrolled, and lets you replace the app when you change phone. Replacing needs your password, and your account is not usable in between, so have the new device with you.
Passkeys let you sign in with the fingerprint, face or screen lock on a device you already trust. Add one per device, name it after the device, and remove it when the device goes. Your authenticator app stays enrolled and still confirms sensitive actions.
Applicant email
Outcome emails leave from your own domain, so somebody who applied to you hears from you. Register an SMTP server or an email provider, and pick one sender as the default.
Credentials are stored encrypted and cannot be read back from this page, not even by you. Saving or removing a sender asks for your authenticator code.
A sender that has not been tested is not used to send
Test it after saving. Until a sender is verified, outcome emails fall back to the shared sender, and the reviewer's decision panel tells them so at the moment they decide.
Testing sends a short message to you rather than to an applicant, because most providers have no way to check a credential without using it.
What each finding means
The account-wide version of the findings policy: what happens when a check reports a specific problem, across every flow. A flow can override any of it.
Findings are always recorded on the result, so an accepted verification still tells you what was noticed about it. Saving asks for your authenticator code, because it decides which applicants are refused across your whole account.
Re-verification
Whether a new verification is refused when you already hold an approval for that person.
The same setting also refuses a new verification while that person has an earlier one waiting on manual review, unless that earlier one is a failed attempt the applicant was invited to retry, and it takes a person's other open review cases off the queue once one of their verifications is approved. Manual review describes what your reviewers see.
This is on by default
While it is on, a create call for somebody you have already approved is refused, and nothing is charged. If your integration is not expecting that, it needs to handle a refusal instead of a session before you rely on this.
How far one approval reaches is per flow or account-wide. Per flow suits an account running several businesses, where an approval on one says nothing about another.
Stop refusing once the document expires lets somebody verify again the moment the document behind their approval runs out, with nobody doing anything.
Re-verify everyone after a number of days lapses approvals on age alone. Leave it empty for no time limit, but read the warning if you also leave document expiry off: with neither, an approval refuses repeats forever and every exception has to be allowed by hand from the verification itself.
Also match on the document catches a repeat even when the create call carried no identifier, by checking the document the applicant presents. That includes the national id printed on it, so a person approved on an ID card is still recognised when they come back with a driving licence or a passport. Without it, sending no reference gets around the refusal entirely.
Country and nationality rules
State your market rules once and every flow inherits them, including flows you create later. A flow can drop an inherited entry for itself, and the page lists the flows that have done so.
The distinction matters: rules about the document say where it was issued, and rules about the person say what they are a national of, which a second passport does not change. The same controls, per flow, are described under flow acceptance policy.
This is owner-only until an owner hands it to somebody, and saving asks for your authenticator code.
Developer alerts
Addresses we email when something goes wrong with your integration, with a log of what happened. Alerts about one endpoint are grouped, so an outage is one message rather than one per lost event.
Choose which environments each address hears about. Sandbox failures are your own tests; live failures are your customers.
Each address receives one confirmation message and stays pending, receiving nothing, until somebody there confirms. You can send the confirmation again from the table. With no addresses registered, nobody is told when your integration drops an event.