Cookie Monster (Consumer Portal)

Unified B2C consumer portal and ordering front-end for multiple RBS platforms via a platform-adapter pattern. One app, many storefronts — the global landing is a directory of active tenant portals.

URL: cookies.redbroomsoftware.comStatus: LIVE Tier: T2 (narrow surface) SDK: @r-bsoftware/ecosystem-sdk — rateLimit

What it is

Cookie Monster is the consumer-facing ordering, account, notifications, referral, and invoice-request surface for the ecosystem. Each tenant is reached via /[platform]/[tenant]/... — a platform adapter (caracol, cosmos-pet, continua, la-hoja, baul, cookies) resolves the tenant on each request and mediates calls to the upstream platform. Cookie Monster does not own SKU or POS state; it proxies to the platform and keeps a local Firestore cache of orders, FCM device tokens, and referral state.

Authentication

• Consumer sessions — phone OTP (primary) or Camino OAuth2/PKCE; resolved into locals.consumer. Authenticated routes return 401 without a session.
• Platform sync — inbound POST /api/portals/sync from platform apps uses an X-Platform-Key header (timing-safe comparison against PLATFORM_SYNC_KEY), not HMAC. This is asymmetric auth on purpose — the key is a shared secret per platform.
• Public order-status poll — GET /api/orders/:orderId/status is unauthenticated so checkout can poll payment state before the session exists. Only exposes status fields — no PII.

Per-IP rate limiting via rateLimit from the ecosystem SDK (30 orders/min, 5 leads/min).

Base URL

https://cookies.redbroomsoftware.com

Primary endpoints

Method	Path
GET, POST	/api/ecosystem/upsell
POST	/api/leads
GET, POST, PATCH	/api/notifications
POST	/api/orders
GET	/api/orders/:orderId/status
POST, DELETE	/api/portals/sync
GET, POST	/api/referrals
GET, POST	/api/referrals/founding-badge
POST	/api/subscriptions
GET, POST	/api/support

15 total — 2 admin/cron/internal (hidden) — +3 more primary endpoints not shown. Source: src/routes/api/**/+server.{ts,js} in the cookie-monster repo.

Events emitted

This app does not currently emit ecosystem webhooks. See the events registry for full catalog.

Events consumed

This app does not currently consume ecosystem webhooks. See the events registry for full catalog.

OpenAPI

Legacy reference with request/response schemas lives at /api/cookie-monster/ until Phase C consolidation.

SDK helpers

import { rateLimit } from '@r-bsoftware/ecosystem-sdk'

rateLimit guards /api/orders (30/min) and /api/leads (5/min). Standard HMAC webhook verification for /api/webhooks/payment uses createWebhookHandler internally.

Gotchas

• /api/orders/:orderId/status is intentionally public — it's inside PUBLIC_API_PREFIXES because the checkout polls before the session is established. Expose only status fields; never add PII or financial totals to its response.
• Portal sync (/api/portals/sync) uses X-Platform-Key with a timing-safe compare — it is not HMAC-signed. Don't reach for createWebhookHandler here; the sync is asymmetric config-push from platform apps.
• Orders live in Firestore orders/{orderId}, not in the upstream platform — cross-reference via platform_order_id and adapter fields.
• Phone normalization is delegated to the upstream platform adapter (Caracol normalizes Mexican numbers server-side). Pass the phone in any format.
• Invoice requests do not live in Cookie Monster — they land on the upstream platform (e.g., Caracol /api/consumer/tenants/:tenantId/invoice-requests) which forwards to Constanza for CFDI stamping.