The conversion pipeline as a TypeScript package.
Domain types, zod validation, adapter contracts, queue and outbox, attribution parsing, and offline conversion upload behind one mounted handler. You own the UI; the SDK owns the rails.
- Published package: @vizuh/apointoo-sdk, versioned and changelogged
- Adapter contracts for booking, notification, persistence, state, audit, dedup, rate limiting, and conversion
- Runs on Next.js route handlers, Cloudflare Workers, and Node servers
Mount one handler
createBookingHandler returns a Hono app. Mount it under /api/booking and your booking flow exists: validation, scheduling rules, state, notifications.
Parse attribution once
GCLID, fbclid, and UTM helpers normalize the click context at capture time, so every later event references the same identifiers.
Confirm outcomes, upload conversions
When the real outcome happens, confirm sends it through the queue and outbox. Offline conversions reach Google Ads with value and conversion time. Failures retry; logs keep receipts.
import { createBookingHandler } from '@vizuh/apointoo-sdk/server'
import { directConfirmAdapter } from '@vizuh/apointoo-sdk/adapters/booking/direct-confirm'
export const app = createBookingHandler({
config: { /* your tenant config */ },
booking: directConfirmAdapter(),
state: memoryStateStore(),
})
// Mount under /api/booking: Next.js route, Worker, Node serverWhich runtime is required?
Anything that runs Hono: Node 18+, Cloudflare Workers, Deno, Bun. Next.js route handlers are the documented pattern.
Do I have to use every adapter?
No. Adapters are contracts; bring your own implementation for any slot or use the shipped ones.
Where is the reference?
On the Developers page, with examples for mounting, confirming, and uploading conversions.