The 8x8 CPaaS Operations Console is a single-file HTML dashboard that provides a unified view of the 8x8 Communications Platform as a Service stack — SMS messaging, voice calls, video sessions, OTP authentication, chat app messaging (WhatsApp/Viber/LINE), and Omni Shield fraud detection. It is designed for MSP operations teams managing clients who use 8x8 CPaaS for customer communications.

The dashboard gives operators a single screen to monitor channel health across all 8x8 API services, track active alerts and incident severity, view call detail records, and watch the Omni Shield fraud detection feed in real time. It refreshes every 30 seconds and includes a footer status bar showing API call count and system state.

The console is a self-contained single HTML file with no framework dependencies. Chart.js is not used — all rendering is pure DOM manipulation. The data engine runs client-side and follows a try/catch fetch pattern: attempt to call the proxy, fall back to the generator function on any failure.

The proxy endpoints used in this console are custom aggregation paths. They do not correspond to any native 8x8 API endpoint. The real 8x8 CPaaS API is organized around individual channel operations (send an SMS, initiate a call, verify an OTP) — it does not have a native "summary", "alerts", or "fraud feed" endpoint. Those operational views need to be constructed by aggregating multiple API responses in your proxy layer.

Seven KPI tiles run across the top of the console. They are rendered by renderKPIs() on every refresh and animate from their previous value to the new value over 700ms using the anim() function. Each tile has a colored top accent, icon, label, value, subtext, and a delta badge showing direction of change.

The channel health panel shows the operational status of all eight 8x8 API services. Each row shows the service name, its proxy path (as a display label), a latency reading, and a status indicator. Status is one of ok (green), warn (amber), or err (red).

The path column is a UI display label only — these paths are never fetched. Channel health status and latency are generated fresh on every refresh cycle by genChannels().

Platform cards appear to the right of the channel health panel and show aggregate status for the major 8x8 product categories. They are rendered by renderPlatCards() using data from the summary object. Each card shows a delivery rate, uptime percentage, and a count of active sessions.

Section 03 of the console shows a horizontal scrolling strip of recent alert badges rendered by renderAlertStrip(). Each badge shows the incident ID, severity, and a truncated title. Clicking an alert badge could scroll to the incident table — this interaction is present in the source but can be wired to open a detail view.

Alerts are drawn from the full alerts array returned by the /api/8x8/alerts proxy call (or genAlerts() in demo). The strip shows a subset of the most recent alerts. The same data populates the full incident queue table in Section 04.

Demo alert titles include realistic operational scenarios: SMS delivery rate degradation, WhatsApp throughput spikes, OTP failure rate elevation by region, fraud score threshold breaches, IVR timeout spikes, carrier route failovers, and 2FA bypass attempts.

Section 04 is the full incident table, rendered by renderTable(). It shows all incidents from the alerts dataset and supports four filter states: ALL, OPEN, ACK, and RESOLVED. The active filter is highlighted and the row count updates dynamically.

Section 05 shows three side-by-side feed panels at the bottom of the console. Each refreshes on every 30-second cycle.

A sticky footer bar shows four operational status items that update on every refresh cycle.

The proxy must return objects matching these shapes exactly. The rendering functions consume these shapes directly with no transformation layer — field names are hardcoded throughout the render functions.

These are the actual 8x8 CPaaS API endpoints your proxy will call. All authentication uses an API key obtained from the 8x8 Connect Portal (Admin → API Keys). The key is passed as a request header.

Unlike the other stack consoles that wrap a single vendor's API, the 8x8 proxy must do two distinct things: actively fetch data from polling endpoints, and passively receive and store incoming webhooks. Both are required for a fully live console.

The summary endpoint aggregates multiple 8x8 API calls into the single object the KPI strip expects. Your proxy handles all the fan-out — the dashboard only sees one clean object.

• 1
  SMS sent count and delivery rateCall GET https://sms.8x8.com/api/v1/{subAccountId}/reports?startDate=TODAY&endDate=TODAY. Extract totalSent and compute delivery rate from delivered/totalSent.
• 2
  Active calls8x8 Voice API does not expose a native active-call-count endpoint. Track session state via webhooks (call.started / call.ended) and maintain a counter in your proxy's state store.
• 3
  Auth verificationsCall the Verify API status endpoint or aggregate from webhook receipts of verify.success and verify.failed events logged through the day.
• 4
  Chat messagesWhatsApp, Viber, and LINE message counts are available from the 8x8 Connect Portal analytics API if your account tier includes reporting. Alternatively track via inbound/outbound message webhooks.
• 5
  API latencyMeasure the round-trip time of a lightweight ping to the SMS status endpoint from your proxy and return that as api_latency. This is the most meaningful latency signal for MSP operational monitoring.
• 6
  Active alertsReturn the count of currently open items in your proxy's alert store (computed in C4). This must be consistent with what GET /api/8x8/alerts returns.

The alerts endpoint is the most custom piece of this integration. 8x8 does not have a native operational alerts API — your proxy must implement alert generation logic based on thresholds applied to the data it collects.

Each alert object your proxy generates must match the alert data shape documented in Section 11. Assign severity (S1–S4), set initial status to open, and store with a creation timestamp for the age calculation.

Channel health is the only data source currently hard-wired to always use the generator. To wire live channel status, replace the Promise.resolve(genChannels()) line in the master refresh() call with a real apiFetch() call.

Your proxy's /api/8x8/channels endpoint should measure actual API response times for each channel by making lightweight test calls (e.g. a status ping to the SMS API), then return an array of channel objects with latency in milliseconds and status set to ok, warn, or err based on the response. The name, icon, and path fields are display-only and do not need to change.

• ✓
  BASE variable set correctly. If the proxy is on a different origin from the HTML file, BASE must be set to the full proxy URL (e.g. https://your-funcapp.azurewebsites.net). An empty BASE means the dashboard and proxy are on the same origin.
• ✓
  All proxy endpoints return valid JSON. The apiFetch() function falls back silently to the demo generator on any error. If your proxy is returning HTML error pages instead of JSON, the console will show demo data with no error indication. Check the browser Network tab to confirm each proxy endpoint is returning JSON with a 200 status.
• ✓
  API key stored in Key Vault, not in proxy code. Verify the Function App's Application Settings show the Key Vault reference string (@Microsoft.KeyVault(...)), not the actual key value. If the raw key is visible in App Settings, the Key Vault reference did not resolve — check Managed Identity access policies.
• ✓
  Webhooks configured in 8x8 Connect Portal. Navigate to Settings → Webhooks and confirm all four webhook URLs point to your proxy's public HTTPS endpoint. 8x8 webhooks require HTTPS — HTTP will be rejected.
• ✓
  KPI strip shows real numbers after first refresh. In demo mode values are in the 80K–92K range for SMS. In live mode the numbers should reflect your actual account volume. A live SMS count of 0 with active accounts is a signal the reports API call failed or the date range is wrong.
• ✓
  Footer shows real latency. In demo mode, LAST FETCH shows 60–200ms (the artificial delay). In live mode it should reflect your actual proxy response time. Values above 2000ms indicate proxy performance issues.
• ✓
  Channel health feed updating. If channel health always shows the same latency and status distribution as demo mode, the Promise.resolve(genChannels()) line has not been replaced with a live fetch yet — see C5.