Changelog

createdSince has been removed from the reference. Use externalRef, status or updatedSince with limit and an opaque cursor. Keep filters fixed while paging; results retain updatedAt-descending order with application ID as the descending tie-breaker.

Responses include Aegis-Request-Id. When a per-key limiter window is available, RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset describe it; a per-key 429 also includes Retry-After in seconds. Pre-authentication IP refusals omit rate-limit and retry headers. This supersedes the earlier blanket statement that no such headers are sent.

Use POST /v1/applications/{clientId}/login-sessions for an existing case. Omit email to select the current owner, or supply an existing member email. Repeating provisioning can restore the original applicant membership, so it is not the general reissue recipe after membership or ownership changes.

Reconcile uncertain writes before retrying requests that create links, registrations or secrets. Tenant suspension blocks provisioning, new links, member additions and unlocking; application reads, member removal and locking remain available with the required scope.

Follow one application from owner creation and sign-in to teammate invitations, access removal, status reads and paginated retrieval. Copy cURL requests and JavaScript helpers for webhook registration, subscription updates, signature verification and durable status reconciliation.

Find endpoint purposes, required scopes, path parameters, request fields, response bodies and error guidance in the API reference. The endpoint directory links directly to each contract.

Application and information-request reads, intake discovery, member-specific sign-in reissue, membership and lock/unlock are documented together. Separate field definitions explain nullable values, ownership handover, the 20-member cap and repeat-call behavior.

The webhook reference covers registration, events, raw-body signature verification, rotation and recovery. Use the returned secret directly as UTF-8. Process every unseen event and read the application for current status; sequence numbers reflect event allocation and do not guarantee chronological status order.

Follow intake selection, provisioning, private applicant handoff and webhook-triggered reconciliation, with cURL and JavaScript examples. The guide includes information-request rounds, membership, error handling and integration acceptance checks.

Use application filters and opaque cursors for recovery sweeps. Keep externalRef, clientId, HTTP request IDs, write-intent keys and webhook event IDs separate. Reconcile an uncertain write before repeating an operation that creates a resource or credential.

Scopes separate application reads, writes and webhook management. API-key rotation invalidates the old key immediately; arrange a second key for a gradual cutover, then revoke the old one. Webhook secrets use a separate rotation overlap.

Every link the API mints is single use and lives three days. Read expiresAt rather than hardcoding a lifetime. For current reissue guidance, use POST /v1/applications/{clientId}/login-sessions for the existing owner or member; the 10 September update replaces the earlier provisioning-based reissue recipe.

Deliver the returned loginUrl privately through your own email or redirect. The earlier advice not to email loginUrl yourself is withdrawn. Use the application-specific login-sessions route to reissue access. Creating with POST /v1/applications and having compliance staff issue the invitation remains an alternative when they make first contact.

POST /v1/applications returns the application status as it stands, so a repeat call for an existing application is not always pending. Handle every value in the lifecycle vocabulary rather than assuming pending.

redirectPath accepts /upload-documents, /status, /form-parser, /dashboard and /requests; any other value is not applied. The sample loginUrl in the reference is corrected to the /sso path. Use the loginUrl the API returns rather than building it yourself.

externalRef and companyName are not refused when they exceed 200 characters; they are cut to their first 200, so two references that share those characters address the same application. Keep externalRef within 200 characters. An email longer than 320 characters or without @ is refused with 400 invalid-argument.

A 5xx response can carry a code other than internal, so use HTTP status when deciding recovery. For 429, honor Retry-After when present. Use bounded backoff for transient failures, and reconcile uncertain writes before repeating an operation that creates a resource or credential.

When labelId is omitted, the first usable intake label in configured order is used. A usable label has an attached intake pair. Select an explicit label from GET /v1/intakes when you run more than one intake.

The reference clarified intake validation, missing-tenant errors and the empty 405 response to OPTIONS. The per-IP limit applies before authentication. The earlier statement that no rate-limit or Retry-After headers are sent is superseded by the 10 September diagnostic-header entry.

The quick reference carries the current link lifetime, given under Sign-in links live three days and work once, and the glossary defines Information request. Send new integrators there for the facts at a glance.

Suspension stops applicant sign-in and returns 403 for operations that grant access. It does not block every API operation: reads, member removal and locking remain available with the required scope. Resolve suspension before retrying a refused access-granting operation.

Raise a request from the Requests tab, not the Decision tab: typed items (a question, a correction to a specific answer, or a document) with a cover note the applicant sees. Accept each answer or send it back for another round; the request closes itself once every item is accepted.

The documented case tabs are Overview, Application data, Documents, Ownership, Sanctions, Adverse media, Risk evaluation, Notes, Report, Requests, Decision and Manage. Recent activity sits on Overview and decision history on Decision. Notes can have an optional due date and assignee; dated notes feed the deadline views.

A case enters Needs info when your team raises a request or sends an answered item back, and returns to Pending when the applicant submits the round or the request is cancelled. Deciding a case that still has an open request cancels the request.

After submission, applicant corrections to submitted answers and evidence go through information-request rounds, and the form itself is closed. The pages give the initial journey in order: consent, upload, form, ownership, teammates, submit.

Reconciled document values fill unanswered fields automatically, marked AI Filled until the applicant edits them. An answer the applicant typed is not overwritten; document values can instead be offered as suggestions. A missing-document request opens the Requests tab, and only an upload made after the ask satisfies it.

A screen that failed, could not run, is pending or was never run blocks approval. A pending or never-run screen is released when it completes; an MLRO can record an attributed exception only against one that failed or could not run.

The fail-closed table adds a country missing from the risk mapping, which is rejected when the engine is built, and the approval block described under An incomplete adverse-media screen blocks approval.

An applicant or teammate whose link has lapsed can request a new one from the portal sign-in page by entering their email. Your team can still reissue a link from the Manage tab, and an integration can reissue through the API.

While a tenant is suspended, no new applications or sign-in links are issued and links already issued stop working; existing data and staff access are preserved. Ask your Aurora Edge representative to suspend or reactivate.

When an integration omits labelId, the first label with an attached intake pair in configured order is used. Keep the intended default first among usable labels, or have callers send an explicit labelId.

Multi-factor authentication for staff accounts is enabled per deployment. Confirm the setting for your deployment at onboarding.