Stage 15 — Full integration acceptance test for one Austin boutique-hotel pilot. Test mode only — no real guests contacted.
Runs 15 pilot scenarios: connect property, receive reservation, create session, generate concierge link, send test email/SMS, verify idempotency, modify/cancel reservations, test expired/cross-hotel tokens, disconnect, verify no payment data, and staff isolation.
Required documentation for production-ready sign-off.
Cloudbeds uses OAuth 2.0 authorization code flow. Requirements: (1) Register a Cloudbeds Marketplace app to obtain client_id and client_secret. (2) Implement the OAuth redirect flow to obtain access_token and refresh_token. (3) Store tokens AES-GCM encrypted at rest (CLOUDBEDS_ENCRYPTION_KEY). (4) Refresh tokens before expiry (default 8-hour TTL). (5) API base: https://hotels.cloudbeds.com/api/v1.1.
Primary: Cloudbeds webhooks (reservation/created, reservation/modified, reservation/cancelled, reservation/status_changed) registered via Cloudbeds Marketplace. Webhook URL includes an embedded secret token for authentication. Fallback: scheduled polling (syncCloudbedsReservations) for properties without webhook support, runs every 15 minutes. Both methods are idempotent via external_event_id deduplication.
Server-side secrets (never exposed to client): CLOUDBEDS_CLIENT_ID, CLOUDBEDS_CLIENT_SECRET, CLOUDBEDS_ENCRYPTION_KEY (AES-256 hex key for token encryption). Per-hotel: Cloudbeds property ID (account_id), OAuth access/refresh tokens (encrypted). Webhook secret (per-hotel, embedded in webhook URL).
From Cloudbeds reservations: property_id, reservation_id, arrival_date, departure_date, guest_count, reservation_status, room_type, guest_first_name (optional), guest_email (optional), guest_language (optional). NOT collected: payment-card data, passport/government ID, billing details, reservation notes, passwords. Guest phone is only stored when explicitly granted via consent flow — never from Cloudbeds sync.
Configurable via DataRetentionPolicy entity. Defaults: guest sessions 90 days, guest profiles 180 days, AI prompts/responses 30 days, Cloudbeds reservation data 365 days after departure, consent records 7 years (accountability), integration logs 90 days. Expired data is deleted or anonymized (PII fields cleared) per policy. No indefinite retention by default.
Email: Platform built-in SendEmail integration (reaches registered app users). For external guest emails, configure SendGrid or Mailgun (email_provider setting). SMS: Platform built-in or Twilio (sms_provider setting). SMS is only sent when explicit sms_marketing consent exists. Guests can reply STOP to opt out (handleSmsStop function). Email/SMS provider selection is per-hotel configurable in integration settings.
Failed webhook events are logged to IntegrationEventLog with processing_status set to "failed" and error_message (sanitized, no PII). Automatic retry: up to 3 attempts with exponential backoff. Hotel admins can manually retry via the Integration Events tab. Events that exhaust retries are marked as "failed" for manual investigation. All errors are sanitized to prevent PII leakage in logs.
Stage 14 security suite (16 scenarios) verified: no cross-hotel access via URL/API tampering, guest tokens are hotel-scoped, expired/revoked tokens rejected, Cloudbeds credentials never exposed in API responses or URLs, no API keys in client-side JS, duplicate events rejected via idempotency, cancelled reservations do not receive messages, no PII in audit logs, unauthorized users blocked from integration settings. All 16 scenarios passed.
Guest consent captured via ConsentRecord entity: privacy_policy (required), terms_of_service (required), hotel_service (required), marketing_emails (optional), sms_marketing (optional), analytics_tracking (optional), ai_interaction (optional). Consent is versioned (policy_version). Guests can withdraw consent at any time via the Privacy Center or concierge privacy panel. Hotel-specific privacy_policy_url and terms_url supported. AI disclosure text required and shown to guests.
Hotel staff access: HotelUser entity with roles (hotel_admin, hotel_editor, read_only). Staff invited via base44.users.inviteUser. Support workflow: (1) Guest reports issue via Report Content page. (2) Hotel staff view guest sessions in the Guest Sessions tab. (3) Staff can revoke sessions manually. (4) Integration issues visible in Integration Events tab with retry capability. (5) Platform admins access via AdminIntegrations and MonitoringDashboard. (6) All support actions logged in AuditLog. Escalation: contact Base44 support for platform-level issues.
Internal Notice: This integration must not be marked production-ready until all 15 pilot tests pass AND the hotel administrator approves the connection and message templates. Qualified US legal counsel must review all privacy, SMS/email, AI, affiliate, accessibility, and data-retention practices before production deployment. Do not contact real guests until approval is documented.