CaptivateChat — AI-Powered Chat Widget for Your Website

Context for the backend developer

The Playground 2 page lets users configure a CaptivateChat Engage widget (theme, bot name, metadata, appearance, etc.) and currently saves everything to localStorage. We need to move this to a real backend so configs persist across devices and can be managed per user.

What needs to be built

Database table / collection

Store widget configs per user. See Data Schema tab for the full shape.

CRUD REST API

Create, read, update, delete configs. See API Endpoints tab for all routes.

Auth middleware

All endpoints must be authenticated. Users can only access their own configs.

File storage for images

headerImageDataUrl and displayImageDataUrl are currently base64 strings. These should be uploaded to a CDN/object store and replaced with a URL.

Config name field

Each saved config has a user-provided name (e.g. "Homepage Widget"). This is already collected in the UI via a modal prompt.

Current localStorage key (to migrate from)

Frontend

The frontend currently reads/writes from this key:

javascript

localStorage.key: "captivate_playground2_config"

// Shape stored today:
{
  "params": { ... },
  "widgetMode": "in-app",
  "sdkMode": "prod",
  "injectUrlParams": false,
  "injectTarget": "metadata",
  "notificationEmails": "...",
  "configName": "My Widget",      // NEW — added with save modal
  "appearance": { ... },
  "savedAt": "2026-07-07T15:22:00Z"
}

Once the backend API is ready, the frontend will replace localStorage.setItem calls with POST /api/widget-configs and PUT /api/widget-configs/:id.

Authentication requirement

Required

All widget config endpoints must be protected. The frontend will send the user's auth token (JWT / session cookie — whatever auth system is in use) with every request.

Expected auth header:

http

Authorization: Bearer <user_jwt_token>

The backend must validate the token and extract userId to scope all queries — users must never be able to read or modify another user's configs.