Skip to main content

Billing, Security & Team

Identiwise gives each tenant an account portal covering sign-up, the plan, team members and tenant-wide security settings. It is separate from the verification API and from the admin console, and it is not open to the public yet.

Pre-launch

Identiwise has not launched. The account portal (account.identiwise.com) is not live yet, nothing on this site can be purchased, and no plan can be started. This page describes what the portal does today so that you can see it before you commit. See the pricing page for indicative tiers.

1. Plan and usage​

The one metered limit​

MetricDescriptionBehaviour at the limit
API requestsEvery request to /api/v1/* is recorded against the tenant, with the endpoint, method, whether it invoked an AI service, and the request size.Hard limit. Once the calendar month's count passes the plan's requests_per_month, further API requests are answered 429 with {"error":"Monthly request limit exceeded"}.

Requests are the only quota the platform enforces today. Other figures you may see on a plan are recorded for reporting, not applied as limits — see Reporting & Data Export. There is no seat limit: a tenant may add as many team members as it needs.

The portal's Billing & Subscription page shows the current plan name, its monthly price, its monthly request allowance and the subscription status.

Paying for it​

At launch, subscriptions will be sold through a third-party payment provider acting as Merchant of Record. That provider handles the checkout, the buyer terms and sales-tax or VAT handling; its name, terms and tax treatment will be published on this site before any account can be opened.

Until then the portal reflects the truth: no payment method is on file, no invoice is due, and plan changes are not self-service. Invoices, payment methods, plan upgrades and cancellation will be available at launch. The refund policy is published in draft form now.

2. Security controls​

Tenant-wide policies live on the portal's Security page. Global policies are editable by the account owner; the rest of the page is visible to the whole team.

IP allow list​

Restrict which source addresses may use your tenant's API.

  • Format: one entry per line, an IPv4 address (203.0.113.10) or an IPv4 CIDR range (203.0.113.0/24, mask 1–32). Invalid lines are rejected when you save and your previous list is left unchanged. A /0 entry is refused too: allow-all is expressed by leaving the box empty, not by a /0 line. IPv6 entries are not supported.
  • Empty means off. An empty list is allow all, never deny-all.
  • Effect: with a non-empty list, a request from any other address is refused 403 with {"error":"Your IP is not allowed"} — on every routed endpoint, login included.
  • Plan-gated. The list is applied on plans that include the IP allow-list feature. On a plan without it the list is stored but not applied, so check your plan before you rely on it as a control.
  • Which address is compared: the true client address as the platform sees it after the load balancer, not a client-supplied forwarding header. GET /api/v1/admin/test echoes that value back so you can confirm what the gate will compare.

Because the gate applies to login as well, add your own address before you save a list.

CORS allowed origins​

The Security page has a CORS Allowed Origins box. It is labelled Not yet enforced in the portal, and the same warning applies here:

Stored, not enforced

The values you save are kept as a record of your intent. The API does not emit cross-origin resource-sharing response headers today, so this list restricts nothing and enables nothing. Browser calls to the API from a third-party origin are not supported yet — call the API from your backend, or use the hosted verification UI, which is served from your own tenant host. See Web integration.

Two-factor authentication​

  • TOTP (any authenticator app) with single-use recovery codes, enrolled by each user on the Security page.
  • Tenant-wide enforcement. Switching on Enforce 2FA for All Team Members takes effect at each user's next login: in the portal a user without 2FA is sent into the setup wizard before they can go anywhere else, and the API's interactive admin login answers 403 for a user who has not enrolled. Bearer tokens already issued are deliberately unaffected — they are machine credentials, not interactive sessions.
  • Attempt lockout. Five failed second-factor attempts within 15 minutes lock sign-in verification for that user. The window clears itself; an owner can clear it immediately with Reset 2FA on the Team page, which also retires the authenticator so the user re-enrols. While a user is locked the Team page shows a 2FA locked badge on their row.

Passwords and sessions​

  • Every password a person chooses — at registration, when an owner adds a team member, when an administrator creates a system user through the API, and at self-service change — goes through one shared password policy.
  • Any user can change their own password on the Security page after re-entering the current one.
  • Changing a password ends that user's other portal sessions on their next request, cancels any outstanding login challenge, and optionally revokes that user's own API tokens (a checkbox on the form). A sign-in to the admin console is not a portal session — it holds a 7-day API token — so it keeps working unless that checkbox is ticked. Tick it if the password may have been compromised.
  • Login rate limiting. Repeated failed sign-ins from one address are refused with 429 and a Retry-After header (20 failures per 15 minutes), before any password is checked. A second, higher ceiling counts every sign-in attempt from that address — successful or not — at 100 per 15 minutes, and a successful sign-in does not clear it. Both windows are 15 minutes, everyone behind one NAT address shares a budget, and IPv6 is counted per /64.

API tokens​

Long-lived bearer tokens for your backend are minted and revoked on the Security page. Only superusers may mint or revoke them — the same rule the API enforces on /api/v1/admin/api-tokens. Tokens are stored hashed; the plaintext is shown once, at creation.

3. Team​

Roles​

Every team member has exactly one role. Authorisation is checked in the router, before any handler runs.

RoleWhat it can do
SuperuserEverything below, plus: create, update, suspend and delete system users; mint and revoke API tokens; run the raw data export.
AdminCreate and edit subjects, mint ephemeral tokens, work the review queue (approve, reject, request re-upload, message the subject), view submissions and photos, read usage.
ViewRead-only: the review queue, submissions, submission history and photo access. No writes.

Separately, one or more members carry the account owner flag. Owners are the only people who can edit the tenant-wide security policies, reset another member's 2FA, remove members, and manage billing when it goes live.

Adding and removing members​

  • Add: an owner opens Add Team Member, enters a name, e-mail, initial password and role. There is no invitation e-mail — the platform sends no e-mail of any kind, so you hand the initial password to the person yourself, over a channel you trust. They can change it on the Security page once signed in.
  • Reset 2FA: clears the member's authenticator, recovery codes, outstanding login challenges and any attempt lockout. They sign in with a password only until they re-enrol.
  • Remove: deletes the account. A live session is checked against the user's row on every request, so removing, suspending or demoting a member takes effect on their very next request — not at their next login.