Identity and Customers

Identity is one of the most important AppActor concepts because it changes how restores, retries, cached state, and attribution behave.

​

Anonymous first is supported

If you configure AppActor without an explicit appUserId, the SDK can start with an anonymous identity. This is useful for:

• trying purchases before account creation
• onboarding-first purchase flows
• apps that do not require login before checkout

​

Stable appUserId is recommended for account-based apps

If your app already has accounts, prefer a stable appUserId for every install and device. This gives you:

• cleaner access continuity after reinstall
• better purchase recovery behavior
• a more reliable mapping between your app account and AppActor customer state

​

Common identity paths

• Configure with appUserId when the user is already known during bootstrap.
• Configure anonymously, then logIn() when purchase access starts before account creation.
• logOut() when the signed-in user leaves and you want to return to an anonymous or cleared local state.
• reset() when you need a stronger local wipe than logout.

​

Customer info is the access contract

Across SDKs, customerInfo is the object you use to answer questions like:

• Does the customer have the premium entitlement?
• Which subscriptions are active, expired, refunded, or grace-period affected?
• Was the result computed offline or pulled from fresh server-backed state?
• What verification or retry metadata came back with the state?

​

Identity details that change real integrations

• Know whether a platform starts with a cached anonymous user or creates one on first configure.
• Know what logOut() clears locally and what it does not do on the backend.
• Know how configure(appUserId:) differs from logIn(appUserId).
• Know what pre-configure getters return on wrapper SDKs.
• Know how identity transitions affect attribution helpers and cached customer state.