I’m hitting what looks like a gap in the RevenueCat v2 API and wanted to sanity-check with others + give RC more visibility.
Context
-
I rely on canonicalizing App User IDs across anonymous IDs and migrations.
-
The Dashboard correctly shows:
-
Original App User ID -
All
App User IDs(aliases)
-
-
Webhooks also include
original_app_user_idand a fullaliases[]array.
Problem (v2 API)
-
GET /v2/projects/{project_id}/customers/{id}returns a minimal customer object.-
No
original_app_user_id -
No aliases
-
-
Calling
GET /v2/projects/{project_id}/customers/{id}/aliaseswith a non-canonical alias often returns only that same ID (i.e. not the full alias graph the Dashboard shows). -
Result: the Dashboard and webhooks have the correct graph, but the v2 “Get customer” read doesn’t expose it, and the aliases endpoint behaves as if it’s scoped to the ID you queried rather than the canonical grouping.
Expected
-
Either
GET /customers/{id}includesoriginal_app_user_id(and optionally aliases), or -
GET /customers/{id}/aliasesreturns the full alias set regardless of which alias you query (or at least documents that you must call it with the canonical/original ID, and provide a way to discover that canonical ID via reads).
Observed logs
-
Dashboard shows:
-
Original App User ID:$RCAnonymousID:…1ac0… -
Aliases:
$RCAnonymousID:…7aa7…,$RCAnonymousID:…123d…, etc.
-
-
API calls within 2 minutes of each other:
-
GET /customers/{alias}→ minimal payload (nooriginal_app_user_id) -
GET /customers/{alias}/active_entitlements→ OK -
GET /customers/{alias}/aliases→ returns only[{ app_user_id: alias }]
-
Ask for RevenueCat
-
Please align v2 “customer” reads with the Dashboard/Webhook truth:
-
expose
original_app_user_id(and ideally aliases) onGET /customers/{id}, or -
ensure
GET /customers/{id}/aliasesreturns the full graph from any member ID (or document the requirement and provide a read to discover the canonical/original ID).
-
If I’m missing a documented flag or expansion that returns the canonical/aliases via v2 reads, happy to try it.
