Overview
Every Despia app needs a single, consistent user identifier (app_user_id) that persists across sessions and devices. This identifier connects all your services together.
Identity Resolution
On every app launch, resolve the user’s identity using this priority:Implementation
Important: The RevenueCat purchase history recovery (Step 2) is critical for apps with in-app purchases. It allows paying users to recover their identity on new devices. If you’re not using RevenueCat, comment out that block and the identity will fall through to the install ID.
Flow Diagram
Note: The getpurchasehistory:// step is RevenueCat-specific. If not using RevenueCat, the flow goes directly from “Vault not found” to “Use install_id”.
Paywall Readiness
Before launching a paywall, ensure both identity resolution and database sync are complete:User Login (Claim vs Recover)
When a user authenticates, the backend determines whether to claim the current identity or recover an existing one.Login Actions
Client-Side Implementation
Backend API Endpoints
User Registration Endpoint
This endpoint receives identity syncs from the app on every launch:User Login Endpoint
Login Flow Diagram
Syncing to Services
After identity resolution, sync theapp_user_id to all integrated services.
Generic Sync Pattern
Restore Purchases (Required for App Store)
Provide a restore purchases button for users who need to recover their subscriptions on a new device. This is required by both Apple and Google.Where to Place the Restore Button
- Settings screen (most common)
- Paywall screen
- Account or profile screen
- Onboarding flow for returning users
Integration Examples
RevenueCat (In-App Purchases) — Deep Integration
RevenueCat is deeply integrated into Despia. Theapp_user_id is passed as external_id when launching paywalls.
Purchase Response Fields
Thegetpurchasehistory:// response includes:
Hybrid Payment Example (Native + Web)
OneSignal (Push Notifications)
Stripe (Web-Based Payments)
For web-based services like Stripe, sync via your backend:Generic Web SDK Pattern
For any web-based SDK, follow this pattern:Database Schema
Store theapp_user_id as the primary link across all tables:
Summary
The
app_user_id is the single source of truth. Every service integration should either accept it directly or map their internal IDs back to it via your backend.