Integration guide

Two endpoints cover every provisioning scenario. Which one you use comes down to whether the applicant is in front of you right now, and how you plan to reconcile the outcome.

Choosing an endpoint

Situation	Endpoint
The applicant is on your site right now and you want to hand them straight into onboarding	`/v1/login-sessions`, redirect immediately
Your compliance team will reach out separately	`/v1/applications`
You want to pre-create a cohort from a CRM export	`/v1/applications` for each, then have staff issue links from the dashboard

Recipe: hand off a user who is already on your site

This is what the two-minute link expiry is designed for.

Call /v1/login-sessions

Your server calls the endpoint with the applicant's email and your externalRef.

Store the clientId

Persist the returned clientId against your own record.

Redirect immediately

Issue an HTTP redirect to loginUrl in the same request cycle.

Treat loginUrl as a credential

Do not render the link into a page the user might read later, and do not log it.

Recipe: onboard someone by email

Because a minted link expires in about two minutes, do not email loginUrl yourself.

Call /v1/applications

Create the application and capture the clientId.

Let the dashboard issue the invitation

Have your compliance team issue the invitation from the dashboard, which sends the applicant a link with an expiry appropriate to email. Alternatively, send your own message directing them to contact you when they are ready to complete it.

If the applicant lets a link lapse, a fresh one can always be issued. Teammates can request their own replacement link from the portal without staff involvement.

Reconciliation

There is no programmatic way to learn an application's outcome. The API provisions applications; it does not report on them. Plan for this explicitly rather than discovering it late.

Persist clientId and your own externalRef at provisioning time.
Reconcile outcomes through the compliance dashboard.
Design your data model so an outcome can be attached later, rather than assuming a synchronous result.

Raise this during scoping

This is the single most common surprise in an Aegis integration.

Error handling

Treat 401 and 403 as configuration problems, not transient ones. Do not retry them in a loop.
Retry 429 and 500 with exponential backoff and jitter.
Treat 410 as permanent for that applicant identity: the record was erased under a data-governance request and will not come back.
Because provisioning is idempotent, a retry after a timeout is safe and will not create a duplicate.

The full error table is in Onboarding API reference.

Going live

Confirm your intake labels

Check which intake labels exist and whether you must send labelId explicitly.

Build against a test tenant

There is no self-serve sandbox. Ask Aurora Edge for a test tenant so your first end-to-end runs do not land in your live case book.

Obtain a production API key

Request it from Aurora Edge and capture the secret into a secret manager at the moment it is issued. It is shown once and never again.

Check your outbound IP

Verify your server's outbound IP will stay within the per-IP limit if it is shared.

Agree the reconciliation process

Settle with your compliance team how outcomes get back to your systems, since the API will not tell you.

Run an end-to-end test

Complete a real applicant journey before enabling it for volume.