apointoo.

Deployment

Environments, variables, queue, and the production checklist.

Deployment

For the hosted dashboard, start with Getting started. Runtime, queue and store sections below apply when hosting your own SDK integration.

Where it runs

Any runtime that executes Hono: Node 18+, Cloudflare Workers, Deno, Bun. Next.js route handlers are the documented pattern.

Variables

.env.local for local development. In production, define them in the platform environment (Vercel, Worker Secrets). For a server integration, use APOINTOO_TENANT_KEY if that is the name the route reads. Do not expose that key with NEXT_PUBLIC_. Integrations calling the dashboard directly from the browser have their own contract; use the generated instructions for that flow. Never put email provider keys in the browser.

Check the project serving the domain, target environment and exact names read by the code. Save and redeploy each affected website. Editing a variable does not update existing builds. After key rotation, update every consumer. Use placeholders only in .env.example.

Queue and outbox

Conversion uploads flow through the queue with an outbox. A transient Google failure does not break the confirm; the attempt retries on schedule. Without persistence configured, memory stores are for development only.

Deduplication

Keep the idempotency key beside the record. A repeated confirm returns the same result; nothing doubles at the destination.

Production checklist

  • NEXT_PUBLIC_SITE_URL points at the canonical host (www).
  • Server integration keys live server-side only.
  • Website redeployed after environment variable changes.
  • Live submission matched in dashboard; email checked separately.
  • A persistent state store is configured (not memory).
  • Consent gates capture.
  • Revalidation webhook wired if you run a CMS.
  • Delivery logs reachable by the team that responds to incidents.
Was this page helpful?