Embedded client experience
Render Smoozen inside the client website while the client controls branding, identity, consent, and final checkout.
Bounded and reviewable
SmoozenExplore
Client integrations
Meet users where the client already serves them.
Smoozen is an optional intelligence provider. A client remains the system of record and can disable Smoozen without losing core operations.
Integration patterns
Choose the surface that fits the operating model.
Each pattern keeps tenant identity deterministic, credentials server-side, and consequential decisions with the client.
Client-branded URL
Use a memorable tenant route such as client.smoozen.com for a white-label planning surface.
Bounded and reviewableServer-to-server REST
Use signed, tenant-scoped requests for the fast path. Never infer tenant identity from user text or model output.
Bounded and reviewableAsynchronous callbacks
Use bounded jobs and HMAC-signed webhooks only for slow operations, with retries, replay protection, and manual fallback.
Bounded and reviewableBefore enablement
A safe integration is a sequence, not a switch.
- 01Prepare
Name the client system of record, tenant, roles, consent purpose, and accountable owner.
- 02Verify
Pin exact origins, validate credentials server-side, test failure and replay paths, and keep the capability disabled by default.
- 03Handoff
Return advisory output to the client workflow; let the client decide, record, book, pay, and communicate.
Gate interpretation
Dates, approvals, and authority are separate controls.
Work cannot start before the stated earliest-start date.
A passed date never substitutes for contract, security, privacy, safety, operations, and rollback approval.
The client remains canonical for identity, consent, booking, payment, safety, and final records.
Earliest-start gates
Deferred work stays deferred until its gate and approval path are complete.
Dates below mean do not start before. They do not authorize implementation automatically.
Earliest start: after 2026-08-22
WhatsApp and M-Pesa/payment implementation cannot start before this date. The date is an earliest-start gate, not authorization.
Earliest start: after 2026-09-01
PMS connectors, hotel credentials, live guest checkout, and OTA/travel APIs cannot start before this date and still require separate approval.
Always separately approved
A date passing does not enable an integration. Contract, security, privacy, safety, operational, and rollback evidence remain required.
Disabled by default
Review safety boundariesAI can assist. Deterministic client controls decide.
Publication, booking, payments, safety actions, network distribution, and user-facing canonical records require the appropriate client workflow and human approval.