app_user_id
For engineers wiring Zellify into a user-aware system. You'll have a single definition you can link to from code reviews and internal docs. You need familiarity with your payment provider's metadata model.
What it is#
app_user_id is a UUID Zellify generates once per funnel session. It persists from the moment the session starts through registration, payment, and the success page. It is the stable identifier you should store alongside user accounts in your system.
It is not the funnel id. It is not the Zellify organization id. It is the identifier of a single visitor's journey through a funnel.
Where it appears (three locations)#
The value is the same in all three locations. The field name differs by surface:
| Surface | Field name | Casing |
|---|---|---|
| Registration webhook payload | context.appUserId | camelCase |
| Stripe Customer / Checkout Session metadata | app_user_id | snake_case |
| Paddle Customer custom data | app_user_id | snake_case |
| Solidgate Customer metadata | app_user_id | snake_case |
| Deep Link Button URL | {{app_user_id}} | template token |
Camel vs snake case#
Historical. Zellify's webhook payload predates its payment metadata contract and ships with camelCase keys. The payment metadata contract uses snake_case because Stripe and Paddle both prefer it.
The values are identical. A reader comparing a webhook payload and a Stripe Customer should match on value, not field name.
Idempotency patterns#
Use app_user_id as the idempotency key when you process a payment event. If the same event is delivered twice (retries, replays, reconnects), looking up your database by app_user_id keeps writes safe.
Do not use email for matching#
Email is mutable. A user changes it, a partner types it wrong at checkout, a test account shares it across three real users. app_user_id is immutable for the lifetime of a session and carries through every downstream surface.
Use email for display. Use app_user_id for matching.