이 번역은 기계로 생성되었으며 검토를 기다리고 있습니다.영어로 전환
이 페이지의 내용

Multiple domains: hosted verification per domain

If your organisation runs several websites, or operates as more than one company, each domain can show its own business name, privacy page and support page on the hosted verification page. You keep one workspace and one set of server keys. You set only what differs for a domain; every other value follows your organisation’s default configuration.

Nothing changes for an existing integration. A domain that has no override, and a session that names no domain, use your organisation’s configuration exactly as before.

What it is

Availability: Controlled availability. Identity verification is provisioned per tenant by your account team; see the product page for the overview and the limits of the result.

Four terms carry the whole page:

  • Domain. A website origin registered under Backoffice → Administration → Domains, with its own site key (Domains, site keys and the install card).
  • Organisation default. The hosted verification configuration you already maintain under Identity Verification → KYC Invitations → Settings (Invitations and hosted verification settings).
  • Domain override. The fields that differ for one domain. A field you do not set on the domain is inherited from the organisation default.
  • Domain of an invitation. Every hosted verification link is created for one domain, or for none. The link carries that choice, and the hosted page shows that domain’s configuration.

These fields can differ per domain:

FieldWhat it controls on the hosted page
Business nameThe organisation name at the top of the page.
Verification purposeThe plain-language reason shown before the customer agrees to continue.
Privacy policy URLThe privacy notice link. A complete https address.
Privacy notice versionThe version label that consent records are tied to.
Support URLThe help link. An https address, or none.
Supported documentsThe document types and issuing countries the customer may choose.
Verification checksWhether a selfie, a spoken number and a file upload from the device are required or allowed, and the liveness mode.
Allowed return hostsThe host names a returnUrl may point to.
Allowed embed originsThe origins allowed to show the hosted page in a frame on this domain, where framing is available for your organisation. An empty list allows none.
Email verificationWhether the customer confirms an email address: Off, Optional or Required.

How inheritance works

For every field, the hosted page uses the earliest value it finds: the domain’s value, then your organisation default, then the built-in default for that field (the built-in default applies only when your organisation has no default configuration at all).

  • A field you leave on “Use tenant default” is inherited. If you change the organisation default later, every domain that inherits that field changes with it.
  • A list is replaced whole. Supported documents, allowed return hosts and allowed embed origins on a domain never add to the organisation’s list. An empty list is a real choice: no return hosts for this domain, or no embedding on this domain.
  • The support URL has a third state. Leave it unset to inherit the organisation’s support link. Set it to none to show no support link on this domain, even when the organisation default has one.
  • Five fields must have a value. Business name, purpose, privacy URL, privacy notice version and supported documents must come from the domain or from the organisation default. If one has neither, the customer of that domain sees “Verification isn’t ready yet” and the readiness status of that domain reports it as not ready. A domain can therefore stand alone: you do not need an organisation default for a domain that has all five.
  • Set the privacy notice version with the privacy URL. Consent records are tied to the privacy notice version. A domain with its own privacy page should have its own version; Backoffice warns when you change the address and leave the version inherited.
  • Open links follow later edits. A hosted page reads its domain’s configuration each time it loads. If you delete a domain override, the links already sent for that domain show the organisation default from then on.
  • Return hosts and the email verification mode stay with the link. They are checked when the invitation is created, against the domain you chose, and stay as they were when the link was created. Editing them later does not change a link you already sent.
  • The legal basis stays organisation-wide. You record it once and it covers every domain. If a domain operates as a different company, decide with your own counsel whether it needs a separate basis; Noxtica does not choose one for you, and the legal basis cannot be recorded per domain today.

Which domain an invitation uses

Noxtica picks the domain on the server when the invitation is created. The rules are tried in this order and the search stops at the earliest match:

  1. The domainId you send.
  2. The siteKey you send, which is the site key of a registered domain.
  3. The Origin header of the request, when it exactly matches an active domain of your organisation. An Origin that matches nothing is ignored.
  4. None. The invitation uses the organisation default.

If domainId and siteKey name different domains, the request is refused with 400 and domain_mismatch. If a domainId or siteKey is unknown, belongs to a disabled domain or does not belong to your organisation, the request is refused with 404 and domain_not_found. All three cases give the same answer, so a refusal never confirms that a domain exists elsewhere.

Prerequisites

  • Identity verification is provisioned for your organisation, and the organisation default hosted verification page is configured, or you configure every required field on the domain (Invitations and hosted verification settings).
  • At least one registered, active domain (Domains, site keys and the install card).
  • An administrator account with fresh step-up verification available. Saving or resetting a domain’s configuration asks for it, as saving the organisation default does.
  • For the API: a server key with the “Verify identity documents (KYC)” permission (Identity verification integration). Server keys start with sk_prod_.

Steps

1. Choose the domain in Backoffice

Open Backoffice → Identity Verification → KYC Invitations → Settings. Under Configuration for, choose Tenant default (all domains) or one domain. The choice is kept in the address as ?domainId=<id>, so you can share a link to a domain’s settings. With Tenant default (all domains) selected, the page is the one you already know.

2. Override only what differs

With a domain selected, every field shows Inherited from tenant default or Overridden for this domain. Use the Override and Use tenant default switch on each field.

  • Copy from tenant default fills every field with the organisation’s current values as explicit values for this domain, so you can edit from there. Those fields stop following the organisation default.
  • Reset to tenant default removes the domain’s override after a confirmation. The domain then uses the organisation default for every field.
  • A summary table lists every domain with the number of fields it overrides.

Select Save configuration. Saving asks for a fresh step-up verification. Saving a domain with every field on Use tenant default stores no override.

3. Read the readiness of the domain

The setup status of the Settings tab and the invitation form evaluate the domain you chose. A domain whose five required values do not resolve cannot start invitations: Backoffice refuses with kyc_not_ready for that domain, while other domains are unaffected.

4. Create an invitation for a domain in Backoffice

Select New invitation. The form has a Domain field. It starts on the domain selected on the page; choose another domain, or the organisation default, when the invitation belongs there. The History table has a Domain column and a filter, so you can follow the invitations of one domain. The Integration tab of Identity Verification → KYC Verifications shows the copy-ready values and samples for the domain you selected, including domainId.

5. Create a session for a domain by API

Add domainId or siteKey to the request of Identity verification integration. Both fields are optional.

FieldTypeRequiredNotes
domainIdstringNoThe id of a registered, active domain of your organisation.
siteKeystringNoThe site key of a registered, active domain. Use it when your system knows the key and not the id.
curl -sS https://collect.noxtica.com/v1/kyc/sessions \
  -H "Authorization: Bearer $NOXTICA_SERVER_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{"subjectRef":"cust_example","domainId":"<domain-id>"}'
const response = await fetch('https://collect.noxtica.com/v1/kyc/sessions', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.NOXTICA_SERVER_KEY}`,
    'Content-Type': 'application/json',
    'Idempotency-Key': crypto.randomUUID(),
  },
  body: JSON.stringify({ subjectRef: 'cust_example', siteKey: '<site-key>' }),
});

const body = await response.json();
if (response.status === 404 && body.error === 'domain_not_found') {
  // Unknown, disabled or foreign domain. Do not retry with the same value.
}

The response gains domainId. It is null when the invitation uses the organisation default.

{
  "ok": true,
  "sessionId": "<uuid>",
  "url": "https://verify.noxtica.com/s/<token>",
  "expiresAt": 1790848845000,
  "domainId": "<domain-id>",
  "requestId": "<request-id>"
}

GET https://collect.noxtica.com/v1/kyc/sessions/{sessionId} returns the same domainId under session.

6. Read the configuration that applies to a domain

GET /v1/kyc/config is a read-only route for your server. It needs a server key with the identity permission, like the session routes.

GET https://collect.noxtica.com/v1/kyc/config?domainId=<domain-id>
Authorization: Bearer sk_prod_your_server_key
{
  "ok": true,
  "domainId": "<domain-id>",
  "domain": { "id": "<domain-id>", "origin": "https://shop.example.com" },
  "effective": {
    "businessName": "Example Retail Ltd",
    "purpose": "Confirm your identity to open an account",
    "privacyUrl": "https://shop.example.com/privacy",
    "supportUrl": "https://www.example.com/support",
    "privacyVersion": "2026-10",
    "requireSelfie": true,
    "requireVoice": false,
    "allowDeviceUpload": false,
    "livenessMode": "passive",
    "emailVerification": "off",
    "allowedReturnUrlHosts": [],
    "allowedEmbedOrigins": []
  },
  "sources": { "businessName": "domain", "privacyUrl": "domain", "supportUrl": "tenant" },
  "tenantDefault": { "businessName": "Example Group Ltd", "supportUrl": "https://www.example.com/support" }
}

The examples above are shortened. effective and tenantDefault also carry documents and updatedAt, and sources names every field.

  • effective is what the hosted page of that domain uses. It is null when a required value is missing.
  • sources tells you, for each field, whether the value came from the domain, from your organisation default (tenant) or from a built-in default (platform).
  • tenantDefault is the organisation default, or null when none is saved.
  • Without domainId, the response is the organisation default plus domains, a list of { domainId, origin, overriddenFields } for each domain that has an override.
  • An unknown, disabled or foreign domainId answers 404 with domain_not_found.

There is no route to change the configuration by API. The configuration decides what your customers see on your behalf, and saving it in Backoffice asks for a fresh step-up verification that a server key cannot give. Change it in Backoffice.

7. Business and merchant verification

Business (KYB) and merchant (KYM) session creation accepts the same domainId, siteKey and Origin rules and stores the domain with the session, where those routes are available for your organisation (Business and merchant verification (KYB and KYM)).

These sessions use only the four identity fields of the domain’s configuration: business name, privacy URL, support URL and privacy notice version. When the session’s domain has an override and those fields resolve, the hosted page shows ” privacy policy” and “Support” links next to Noxtica’s own legal links. Without a domain, when the domain has no override, or when the identity is incomplete, the page is unchanged. The verification options (documents, selfie, liveness, email) apply to identity verification only; Backoffice shows the identity fields alone for business and merchant sessions.

What changes for existing integrations

Nothing, until you save a domain override.

  • A request with no domainId and no siteKey creates an invitation for the organisation default, as before. What you see is an extra domainId key, set to null, in the response and in the status read.
  • A request whose Origin header matches no registered domain behaves as before. An origin that matches a registered, active domain selects that domain, and domainId then carries its id. Until you create an override for that domain, the configuration is still the organisation default.
  • Links already sent keep working and keep showing the organisation default.
  • Routes and server keys do not change.

Verify it works

  • In Backoffice, select a domain and save an override that differs from the organisation default, for example another privacy URL and privacy notice version.
  • Create an invitation for that domain and one for the organisation default, and open both links on your own device. The two pages show different privacy and support links.
  • Create a session with domainId set to that domain and read it back: GET /v1/kyc/sessions/{sessionId} returns the same domainId.
  • Call GET /v1/kyc/config?domainId=<domain-id> and check that sources names domain for the fields you overrode.
  • Select Reset to tenant default, reload the link of the domain and check that it now shows the organisation default.

Troubleshooting

SymptomCauseFix
404 with domain_not_foundThe domainId or siteKey is unknown, belongs to a disabled domain or does not belong to your organisation.Check the domain list in Backoffice, enable the domain, or use the id of a domain in your own workspace.
400 with domain_mismatchdomainId and siteKey name different domains.Send one of them.
An invitation shows the organisation default instead of the domainThe request carried no domainId or siteKey, and its Origin did not match an active domain exactly.Send domainId or siteKey.
One domain shows “Verification isn’t ready yet”A required value has neither a domain value nor an organisation default.Set the missing field on the domain or in the organisation default. The readiness status of that domain shows it as not ready.
409 with kyc_not_ready for one domain in BackofficeThe same missing value, seen when creating an invitation.Complete the domain’s required fields.
The domain still shows the old support linkThe domain’s support URL is unset, so it inherits the organisation’s.Set a support URL on the domain, or set it to none.
A warning about the privacy notice versionThe privacy URL is overridden and the version is inherited.Set the privacy notice version for the domain.
A removed embed origin still frames the pageThe embedding check is kept briefly for each link.Wait about a minute.
The page asks for step-up againSaving or resetting a domain’s configuration needs a fresh check.Complete it and repeat the action.