Administration

What your admins configure, and what stays with Aurora Edge. Configuration that could produce an incoherent rating is validated before it can be saved.

Tenant setup

Aurora Edge

Users

Your admins

Forms and risk engines

Your admins

Intake labels

Your admins

API keys

Aurora Edge

Security settings

Your admins

Tenant setup

Aurora Edge provisions your tenant, sets its branding (name, logo, colour, default screening country), and runs data-governance actions on request. A tenant can also be suspended and reactivated as a reversible firm-wide freeze: while suspended, no new applications or sign-in links are issued and links already issued stop working, while existing data and staff access are preserved. Ask your Aurora Edge representative for any of these.

Users

Create staff accounts, set roles, move a user between tenants, disable or remove accounts. Role changes take effect immediately and invalidate stale sessions. The role model is in Roles and access.

Forms and risk engines

A visual form builder and risk-engine editor let you build and version intake pairs in the dashboard. Live coherence validation means an incoherent configuration cannot be saved.

Weights must sum correctly.
Every scored field must exist on the form.
Bands must be valid.

Editing is safe while cases are in flight

The form is frozen per application at creation and the risk engine at first evaluation, so revising an intake never changes what an in-progress applicant sees or what an approved rating was based on. See Core concepts.

Intake labels

Attach a label to a pair to make it live. Applications are provisioned against a label, not against a pair directly. The label id is what your systems send as the optional labelId when provisioning through the Onboarding API. When they omit it, the first label in your configured order is used, so keep the intake you want as the default first.

API keys

Aurora Edge issues, rotates, and revokes the keys your systems use, on request. The secret is shown once at issue and is not recoverable afterwards, so capture it into your secret manager at that moment.

Treat both rotation and revocation as taking effect immediately. Deploy the replacement credential to every caller as part of a coordinated cutover. For a gradual migration, ask for a second key first, switch and verify all callers, then revoke the old key. Requests still presenting an invalidated secret fail with 401 unauthorized. Retain the same provisioning identity when retrying a failed create.

Store the secret in a secret manager

Anyone holding an API secret can perform the operations its scopes grant for your tenant. Keep it server-side, never in source control. See Integration guide for the going-live checklist.

Integration scopes and webhook operations

API keys grant applications:read, applications:write and webhooks:manage according to their assigned scopes. Keys without explicit scopes default to applications:write. Arrange read access for reconciliation and keep webhook management credentials separate where possible. See API authentication.

Staff and tenant integrations can inspect webhook deliveries and dead letters. The defaults are five endpoints and twelve attempts. Aurora Edge can configure bounded tenant-specific limits. A receiver 410 disables its endpoint with an explicit reason. See Webhooks and callbacks for registration, secret overlap and recovery procedures.

Security settings

Multi-factor authentication enrolment for staff accounts, where it is enabled for your deployment. Confirm the setting at onboarding. Full detail is in Security and compliance.