Orbis × LiteAPI

Infrastructure map · 2026-05-01
External service
Cloudflare Worker
Tenant D1 database
New for LiteAPI

Today — Sandbox MVP+

One Worker, one tenant DB, one new table. Bookings made through Leon's WhatsApp DM persist to orbis-dreamlink — the Dreamlink-organization's tenant database — alongside everything else Leon already writes.

LITEAPI · v3.0 api.liteapi.travel 3M+ hotels · merchant of record · sandbox key live KEVIN · WHATSAPP DM "Find me a hotel in Lisbon" via Evolution webhook 5 hotel tools call LiteAPI LEON WORKER · nova-orbis leon/worker/ · Cloudflare Workers · TypeScript + Hono existing tools query · write · send · calendar schedule · experiences · loop browse · briefing · etc. ▸ NEW · 5 HOTEL TOOLS hotel_search hotel_details hotel_prebook hotel_book hotel_cancel + recall via query tool all backed by integrations/liteapi.ts (HTTP client + idempotency) env.DB → legacy env.DB_NEW → primary D1 · NOVA-LEON legacy · being decomposed conversations · group_messages slack_messages · executions leon_errors · contacts (legacy) no new tables go here (root rule) D1 · ORBIS-DREAMLINK tenant database for the Dreamlink organization contacts · access_permissions · memory · knowledge · pm_tasks · pm_deals · ... ▸ hotel_bookings   NEW · sandbox MVP+ id · contact_id · liteapi_booking_id · room_type · bed_config · base_price + taxes + fees · idempotency_key · ... all writes mirror via dual-write wrapper · except new tables (write directly to env.DB_NEW)

The Per-Tenant Model — Future

When NOVA / Happitogether / external customers (Gaku) become their own tenants, each gets their own D1 with the same template. Hotel bookings stay isolated per-tenant — no cross-tenant database, ever.

LITEAPI · ONE ORBIS ACCOUNT commission flows to Orbis Pte Ltd (Singapore) per-tenant trading names: NOVA · Happitogether · Gaku · ... WORKER · DREAMLINK Kevin / NOVA / Happitogether D1 · ORBIS-DREAMLINK contacts · memory · deals tasks · projects · ... hotel_bookings (Kevin's bookings only) live today WORKER · NOVA future spin-out D1 · ORBIS-NOVA NOVA member contacts trips · experiences hotel_bookings (NOVA guests only) v2 — multi-tenant rollout WORKER · HAPPITOGETHER future · wedding planners D1 · ORBIS-HAPPITOGETHER planner + couple contacts events · guests · seating hotel_bookings (blocks) (wedding-block holds) v2 — wedding vertical WORKER · GAKU first external customer D1 · ORBIS-GAKU team · talent deals · projects (may not need hotel tools) agency vertical each Worker reads/writes ONLY its own D1 — no cross-tenant access, ever same hotel_bookings schema (from travel-concierge vertical) · isolated data per tenant

Three Architectural Principles at Play

One tenant, one DB

Every paying customer (and Dreamlink itself, as customer #1) gets their own isolated D1. Names follow orbis-{tenant_id} — never orbis-{feature}. A cross-tenant database would leak data between tenants.

Schema as template, data per-tenant

The hotel_bookings table definition lives in the travel-concierge vertical. It gets stamped into each tenant DB that uses travel features. NOVA's bookings, Happitogether's, and Gaku's never share a row.

One LiteAPI account, fan-in

Orbis Pte Ltd (Singapore) holds one LiteAPI account. All tenant Workers use the same key (a Worker secret). Per-tenant trading names give each tenant its own brand on guest receipts. Commission flows to one Orbis bank account; reconciliation splits per-tenant from the booking IDs.

The "no new tables in nova-leon" rule

nova-leon is the legacy DB being decomposed (Phase 3.A flipped 2026-04-25 into orbis-dreamlink). New data lands in the new home, directly. hotel_bookings is born in orbis-dreamlink; never goes near nova-leon.

For the Sandbox MVP+ — what's new vs what's reused

New for this build

leon/worker/migrations/2026-05-01-hotel-bookings.sql · table migration
leon/worker/src/integrations/liteapi.ts · HTTP client wrapper (new dir)
leon/worker/src/tools/hotel-{search,details,prebook,book,cancel}.ts · 5 tool handlers
orbis-dreamlink.hotel_bookings table · 1 new table, lives in existing DB
LITEAPI_SANDBOX_KEY · 1 Worker secret on nova-orbis
LITEAPI_BASE_URL · 1 var in wrangler.toml

Reused (not modified, just consumed)

orbis-dreamlink D1 · existing — 1 new table inside it
Worker nova-orbis · existing — 5 new tools registered into existing dispatch
LEON_TOOLS / TOOL_INDEX · existing arrays — append 5 entries
clearance/tool-sets.ts · existing — append 5 names to chief-of-staff deferred list
contacts table · existing — booker / guest references via contact_id FK
query tool · existing — register hotel_bookings in catalog so recall works (no new tool)
executions, leon_errors · existing — tools log to these on success/failure
WhatsApp + Evolution webhook · existing — no changes needed

The Stack

Cloudflare Workers Cloudflare D1 (SQLite) Cloudflare R2 TypeScript Hono Vitest 4.x Wrangler 4.x Anthropic Claude (tool loop) LiteAPI v3.0 (sandbox) Evolution API (WhatsApp)
Orbis × LiteAPI · prepared 2026-05-01 · sandbox MVP+ scope