Fictura
Migration

Drift — migrate in

Fictura is designed to be adopted piece by piece, next to everything you already run — and to break nothing if you leave.

The migration story is additive. Nothing asks you to replace your billing spine, your crash reporter, or your subscriptions table on day one — each connection sits beside what exists.

Keep RevenueCat

Fictura consumes RevenueCat's webhook; it doesn't replace RevenueCat. Your purchase code, your entitlement checks, your RevenueCat dashboard all keep working — one pasted URL adds Fictura as a second consumer.

Keep your subscriptions table

Point the billing webhook at the handler you already run. The only real difference from the RevenueCat payload is nesting — theirs under event, ours under data — so the shim is a few lines:

TypeScript
const payload = await req.json();

// Works for both senders: RevenueCat nests under `event`, Fictura under `data`.
const e = payload.event ?? payload.data;
const userId = e.app_user_id;
const productId = e.product_id;
const expiresAt =
  e.expires_at ??
  (e.expiration_at_ms ? new Date(Number(e.expiration_at_ms)).toISOString() : null);

Everything after those lines — your upsert, your status function, your gating — runs unchanged. Or retire the table and ask the entitlements endpoint instead; both derive from the same events.

Keep your error reporter

Fictura's error handlers chain to whatever was installed first, so anything you already run keeps catching exactly what it catches today. Nothing to remove on the way in.

And the exit

The same properties in reverse. Because your spine was never replaced — RevenueCat still fires, your table still fills, your store products still sell — turning Fictura off tomorrow breaks nothing. Web checkout's off switch returns every device to the App Store sheet within one config refresh. That's the drift argument: tools that connect without fusing.

On this page