One user record, not four copies

How it works

1. 1. Install the SDK

   Add @ascendkit/nextjs or the Python SDK and set your project public key. Auth runs through Better Auth with AscendKit as the backing store.
2. 2. Send email against the same record

   Transactional and lifecycle email address usr_ profiles directly. No export, no list sync, no second copy of your users in an email vendor.
3. 3. Add journeys and surveys on top

   Lifecycle journeys trigger on your own product events, and NPS or CSAT responses attach to the same profile — so survey answers are queryable next to auth and email history.

What does syncing four vendors actually cost?

It is not the code you write once. It is that every additional system multiplies the number of paths along which your data can disagree, and each path fails quietly.

With auth and email you have two systems and one sync path. Add lifecycle automation and surveys and you have four systems, which is not four paths but twelve. Each is a webhook that can be dropped, delivered twice, delivered out of order, or simply never fire because a field changed in a system that had no reason to broadcast it.

The failures do not look like failures. A user exists in auth but never receives onboarding. A campaign addresses someone by a name they changed months ago. A survey response cannot be joined to the account that submitted it. None of these raise an error; they arrive as unrelated support tickets.

What does one record let you actually do?

Ask questions that span the lifecycle without a join across four vendors' exports. That is the practical payoff, and it is hard to appreciate until you have tried the alternative.

Because auth, email, journeys, and surveys all address the same usr_ profile, a detractor NPS score sits next to when that user signed up, which onboarding emails they opened, and where they stopped in a journey. On a stitched stack that question requires exporting from four systems and reconciling identifiers that were never designed to match.

It also removes a class of work rather than automating it. There is no reconciliation job, no idempotency key, no dead-letter queue for user records — not because those are handled well, but because there is nothing to reconcile.

What is the honest downside?

Concentration. One record in one platform means one vendor, and that is a real trade rather than a free win.

Two things reduce it without eliminating it. AscendKit is built on Better Auth, which is open source and runs without us, and auth data uses Better Auth's own schema rather than a proprietary user model — so the exit is a database migration rather than a rewrite. Self-serve export is not shipped yet, which is worth weighing before you adopt.

There is also a genuine fit question. If you need best-in-class depth in one area — sophisticated marketing automation, or advanced survey logic — a dedicated tool will beat a bundled one. The bundle wins on coherence, not on depth in any single domain.

FAQ

Related guides

• Replace Clerk and the stack around it — the concrete migration this argument leads to.
• Webhooks for auth and lifecycle events — what webhooks are still genuinely for once syncing is gone.
• AscendKit vs Supabase — the option that keeps users in a Postgres you own.
• How to leave AscendKit — the concentration trade-off, documented rather than glossed.
• Moving off Clerk webhooks — the migration playbook, including the failure modes in detail.
• The stitched stack, compared — cost and complexity of the four-vendor alternative.