Frameworks and integrations

Frameworks and integrations

Apointoo does not require you to replace the experience you already built. The frontend captures the click and publishes journey signals through GTM/dataLayer. The server confirms the real outcome and sends the conversion back to Google Ads. That capture layer uses ClickTrail's tracking basis; Apointoo owns outcome confirmation and configured delivery.

Choose the path

System	Recommended path	Current status
Angular, React, Vue, Svelte, or JavaScript	Use the dataLayer contract for browser signals and a server route for confirmation	Frontend pattern; no framework-specific SDK
Next.js, Node, or Hono	Mount the SDK on the backend and confirm the outcome in the handler	Production with direct-confirm
WordPress	Use Apointoo Capture with existing forms	Published capture path
Stripe	Receive the post-payment webhook server-side and confirm sale_paid or subscription_active	Via API
Boulevard	Use the published booking adapter	Production
Reserve with Google	Use Apointoo's reservation and confirmation flow	Production
OpenDental	Use the published adapter in a controlled environment	Beta
External forms, CRMs, and calendars	Use the webhook/API contract when released; do not invent a native adapter	Several paths are still planned

The integration catalog is the provider status source. Production, Beta, Via API, and Planned are not interchangeable.

Browser contract

Every framework can publish the same events. The framework changes where the code runs, not the contract:

window.dataLayer = window.dataLayer || []
window.dataLayer.push({
  event: 'generate_lead',
  event_id: 'evt_example_001',
  form_id: 'access_request',
  value: 1,
  currency: 'EUR',
})

Use the same event_id in the final dataLayer event and the server POST. Never put email, phone, clinical data, or secrets in the dataLayer. See the local GTM contract for event names, consent, and deduplication.

Framework examples

• Angular: call a helper from the confirmed submit or a tracking service; send the form to your API, not directly to Google Ads.
• React: call the helper from a submit handler or client-only action; never emit generate_lead during render.
• Vue and Svelte: use the submit handler or a composable/store after validation; keep window access out of SSR.
• JavaScript: push before redirecting so GTM can process the event.
• Next.js/Node/Hono: keep the SDK and secrets server-side; the browser only publishes journey events.

Stripe and other payments

Stripe is a post-payment API integration. Stripe Checkout is not an Apointoo browser SDK. The correct path is:

1. Capture attribution before sending the visitor to checkout.
2. Receive and verify the signed webhook on the server.
3. Use an idempotency key from the Stripe event.
4. Confirm the outcome in Apointoo with the real value, currency, and time.
5. Process refunds as corrections, not as a second sale.

PayPal, Mercado Pago, and other processors follow the same boundary until the catalog marks an adapter available. A browser success page does not replace a verified webhook.

Webhooks, CRMs, and custom systems

HubSpot, HighLevel, Pipedrive, Typeform, Jotform, Calendly, Zapier, the Conversions API, and the Read API/Webhooks appear in the catalog as planned paths. Until a status changes:

• treat the external system as the outcome source of truth;
• send the minimum required data through an authenticated endpoint;
• preserve the idempotency key and delivery receipt;
• do not publish the integration as a native production adapter.

Verify before deployment

• The frontend publishes exactly one event per confirmed action.
• event_id matches in the browser, server record, and outcome.
• The selected consent source controls advertising events.
• GTM Preview shows the expected event and variables.
• Payment webhooks verify signatures and retries.
• Logs keep the delivery receipt, not only a “connected” status.