Domain settings

RADKit connects to the cloud through a domain — a named endpoint that identifies a specific RADKit Cloud deployment (e.g. IQ_US for the IQ Cloud production cluster in the US region). Two settings control which domains a client or service uses:

• cloud_client.connect_domains — where to actively connect.

• cloud_client.accept_domains — which forwarder redirects to accept (and a secondary source of connection candidates).

See Settings reference for the individual parameter reference entries.

Domain tree

Domains are organized in a hierarchical tree. A group is a named collection of domains or sub-groups. Groups can be referenced by name in settings and are expanded depth-first when resolved.

IQ_CLOUD  ("IQ Cloud")                ← visible, use in connect_domains
├── IQ_US
├── IQ_EMEA
└── IQ_APJC

CXP_CLOUD  ("CXP Cloud")             ← hidden
├── CXP_US
├── CXP_EMEA
└── CXP_APJC

RADKIT_CLOUD  ("RADKit Cloud")        ← visible (legacy)

STAGE  ("Stage")                      ← hidden (for internal/testing use)
├── IQ_CLOUD_STAGE  ("IQ Cloud Stage")
│   ├── IQ_US_NPRD
│   ├── IQ_EMEA_NPRD
│   ├── IQ_APJC_NPRD
│   └── RADKIT_CLOUD_STAGE
└── CXP_CLOUD_STAGE  ("CXP Cloud Stage")
    ├── CXP_US_NPRD
    ├── CXP_EMEA_NPRD
    ├── CXP_APJC_NPRD
    └── RADKIT_CLOUD_STAGE

DEVEL  ("Devel")                      ← hidden (for development use)
├── IQ_CLOUD_DEVEL  ("IQ Cloud Devel")
│   ├── IQ_DEV_US
│   └── RADKIT_CLOUD_DEVEL
└── CXP_CLOUD_DEVEL  ("CXP Cloud Devel")
    ├── CXP_US_DEV
    └── RADKIT_CLOUD_DEVEL

IQ_CLOUD, CXP_CLOUD, and RADKIT_CLOUD are independent root-level entries. An identity from RADKIT_CLOUD can be used with any production domain, but identities are not reusable across IQ_CLOUD and CXP_CLOUD subtrees. Cross-environment identities (e.g. production vs stage) are never reused.

How domains are resolved

Both settings accept a list of domain names or group names. A group such as "IQ_CLOUD" is a named collection of regional domains (IQ_US, IQ_EMEA, IQ_APJC) and is expanded depth-first when resolved.

The active connection target is determined by the following algorithm:

leaf_connect = deduplicate(flatten(connect_domains))
leaf_accept = deduplicate(flatten(accept_domains))
candidates = deduplicate(leaf_connect + leaf_accept)  # connect takes priority
active = candidates[0]  # first entry wins

connect_domains entries appear first in candidates. accept_domains entries are appended after, minus any already present.

When both lists are empty, candidates is empty and no connection is attempted.

Role of accept_domains

accept_domains serves different purposes depending on the component:

radkit-client — redirect validation and additional connection candidates

When the cloud forwarder redirects the client to a different domain, the target domain is checked against the resolved accept_domains leaf list. Redirects to domains outside this list are rejected. In addition, any accept_domains leaves not already present in leaf_connect are appended to candidates (lower priority).

radkit-service — additional connection candidates only

The service does not receive forwarder redirects. accept_domains entries are appended to candidates after connect_domains leaves, but since fallback only retries connect_domains candidates, accept_domains does not affect which domain the service ultimately connects to. For the service, regional failover is controlled entirely by the order of entries in connect_domains.

Default values

	connect_domains	accept_domains
radkit-client	["IQ_CLOUD"]	["IQ_CLOUD"]
radkit-service	["IQ_CLOUD"]	["IQ_CLOUD"]

Both components connect to the IQ Cloud production group (IQ_US is listed first in the group) out of the box without any configuration.

Common scenarios

Default — connect to IQ Cloud production

No configuration needed. Both client and service use connect_domains = ["IQ_CLOUD"] and accept_domains = ["IQ_CLOUD"] by default, which resolves to:

candidates = [IQ_US, IQ_EMEA, IQ_APJC]

The active connection target is IQ_US (first leaf of the IQ_CLOUD group).

---

Connect to all production domains (IQ + CXP + RADKit Cloud)

# TOML
[cloud_client]
connect_domains = ["IQ_CLOUD", "CXP_CLOUD", "RADKIT_CLOUD"]
accept_domains  = ["IQ_CLOUD", "CXP_CLOUD", "RADKIT_CLOUD"]

# candidates = [IQ_US, IQ_EMEA, IQ_APJC, CXP_US, CXP_EMEA, CXP_APJC, RADKIT_CLOUD]

---

Prefer a specific region

Set connect_domains to put the preferred region first:

# TOML (radkit-client settings.toml)
[cloud_client]
connect_domains = ["IQ_US", "IQ_CLOUD"]
accept_domains  = ["IQ_CLOUD"]

# candidates = [IQ_US, IQ_EMEA, IQ_APJC]
# → connects to IQ_US; falls back to IQ_EMEA then IQ_APJC

---

Service pinned to a single region

Override the defaults to restrict the service to one region:

# TOML (radkit-service settings.toml)
[cloud_client]
connect_domains = ["IQ_US"]
accept_domains  = ["IQ_CLOUD"]

The service connects to IQ_US.

---

CXP Cloud only

To use the CXP Cloud deployment instead of IQ Cloud:

# TOML
[cloud_client]
connect_domains = ["CXP_CLOUD"]
accept_domains  = ["CXP_CLOUD"]

---

CLI — override domain at startup

The --domain flag is a shorthand that sets both connect_domains and accept_domains to the given value:

radkit-client --domain IQ_US
# equivalent to:
# --setting cloud_client.connect_domains '["IQ_US"]'
# --setting cloud_client.accept_domains  '["IQ_US"]'

---

Restrict to a single leaf domain (no redirects)

connect_domains = ["IQ_US"]
accept_domains  = ["IQ_US"]

Only IQ_US is in candidates and only redirects to IQ_US are accepted.

Fallback on missing identity

This section is relevant when using certificate-based authentication (certificate_login for the client, or service identity obtained during enrollment). It applies to both radkit-client and radkit-service.

Each domain issues its own (serial number, certificate) identity pair. An identity from any domain within the same subtree can be used — for example, an IQ_US identity can authenticate to IQ_EMEA because both are leaves of the IQ_CLOUD group. An identity from the root-level RADKIT_CLOUD domain can be used with any production domain. Cross-environment identities (e.g. production vs stage) are never reused.

If no usable identity is found for candidates[0], RADKit tries the next candidate — but only if that candidate originated from connect_domains. Candidates that come exclusively from accept_domains are not tried as fallback targets.

Example:

connect_domains = ["IQ_US", "IQ_EMEA"]
accept_domains  = ["IQ_CLOUD"]

# candidates = [IQ_US, IQ_EMEA, IQ_APJC]
#   IQ_US   → from connect  → tried first
#   IQ_EMEA → from connect  → fallback if no usable identity for IQ_US
#   IQ_APJC → from accept only → NOT tried as fallback