Client entitlement checks are great for UI. Backend resources should be protected by backend checks. Use this split:
  • mobile app: fast UX gating with getCustomerInfo()
  • your backend: authoritative access checks before serving premium API responses, files, AI credits, or expensive generation
  • AppActor: source of truth for entitlement state, purchase receipts, restore, sync, and customer records

Backend request pattern

Call AppActor from your server with a project secret key, never from the app.

Active-only response

The secret-key user lookup is intentionally shaped for access checks. It returns the active entitlement map your backend should gate on, not a full support-history dump of every expired, revoked, or billing-retry entitlement. The SDK helper hasActiveEntitlement("premium") follows the same active-access interpretation. On your backend, check isActive and treat a missing entitlement as no access. For support tooling or analytics, use the dashboard/customer timeline or deeper server surfaces that expose historical status details.

When to call your backend

Use backend access checks before:
  • returning premium API responses
  • starting expensive AI jobs
  • granting consumable credits
  • issuing signed download URLs
  • joining private realtime rooms
  • unlocking support-only recovery actions
Use client checks for:
  • hiding or showing tabs
  • paywall routing
  • optimistic UI after purchase
  • offline continuity while the device reconnects

Do not leak secrets

Keep these values server-only:
  • sk_... project secret keys
  • dashboard session cookies
  • webhook secrets
  • App Store / Google API credentials
Mobile apps should only use public app SDK keys that start with pk_....
For client-side high-trust gating, pair this with Trusted Entitlements.