Members
Every member who can sign in to your AFCore-powered app must first exist in the AdvantaHealth member roster. The roster lives in the AIDE Developer Portal; AIDE owns roster management, eligibility, and program/entitlement assignment.
This page covers only the AFCore-side concern: which sign-in pattern to use and what SDK calls return the member data AIDE manages.
Manage the roster, eligibility, and program assignments in AIDE — see AIDE's own documentation for the workflow.
Two enrollment models
Pick the one that matches your organization's setup in AIDE.
| Model | When | SDK call |
|---|---|---|
| Eligibility file | Members are pre-loaded into AIDE from a sponsor-provided CSV/JSON; you know them before they sign in | authenticateWithCredentials(username, password) |
| SSO / external user id | You issue identities yourself (consumer apps, white-label); AIDE auto-provisions the member on first sign-in | signInOrCreateMember(externalUserId: …) |
Both flows are described under Member Authentication.
Reading member data
Once authenticated, the SDK exposes the AIDE-managed record:
val profile = AFCore.profile().get()
val programs = AFCore.programs().get()
let profile = try await AFCore.shared.profile().get()
let programs = try await AFCore.shared.programs().get()
See Member Profile and Member Programs for the data shapes.
When AIDE changes a member's state
State changes in AIDE (disabled, re-enrolled, program swapped) propagate to the SDK on the next request:
| AIDE change | What AFCore returns next |
|---|---|
| Member disabled | 403 on any authenticated call → SDK emits SessionState.SESSION_EXPIRED |
| Member re-enrolled | Sign-in succeeds again on next attempt |
| Program / entitlements swapped | Next programs() call returns the new set |
Treat the SDK as a read-through view of AIDE — never cache entitlement decisions longer than a session.