The Admin Insights console is a two-page single-file HTML dashboard. The Security Operations page gives NOC/SOC engineers a unified threat view across all security platforms — active endpoint detections, firewall events, IPS alerts, alert severity breakdown, and a threat timeline. The Ticket & Workload page gives service desk managers visibility into engineer capacity, ticket aging buckets, per-client ticket volume, and weekly throughput.

The two pages are mutually exclusive — only one is active at a time. Switching pages clears the auto-refresh interval for the previous page and starts a new 30-second interval for the newly active one. Each page loads independently, so the Security page can be left open for wall display while workload data loads on demand.

The console is a self-contained single HTML file with no framework or CDN dependencies — all rendering is pure DOM manipulation, all charts are hand-drawn SVG. The data engine uses two fetch functions that call your proxy, each with a 6-second timeout and silent fallback.

Every vendor referenced in the dashboard was audited against live API documentation before wiring. The following table documents the findings — what the dashboard shows, what real API backs it, and any constraints you need to know before building the proxy layer.

Five KPI tiles across the top of the Security Operations page, rendered by renderSecurityKPIs(kpis). Each tile has a label, large value, sub-label, and a color class (danger/warn/ok/info) that sets its border accent.

Rendered by renderThreats(threats). Shows a card per threat event with a colored severity dot, threat type, platform source, host name, client name, and time-ago string. Sorted by recency.

Rendered by renderFWEvents(events). A five-column table showing event type, source IP, client, event count, and severity badge. Data comes from FortiGate's log endpoints — your proxy aggregates and groups log entries by source IP and event type.

Rendered by renderAlertSummary(summary). Four horizontal bar gauges showing the proportion of Critical / High / Medium / Low alerts. Each bar fills proportionally to its share of the total. Source: alertSummary: {critical, high, medium, low} — integer counts from your proxy.

In production these counts are the aggregate of all cross-platform alerts — SentinelOne threats + Huntress incidents + FortiGate events — bucketed into the four severity levels. Your proxy normalizes vendor-specific severity naming before returning.

Rendered by renderTopClients(clients). A three-column table: client name, total alert count, and a severity badge for their highest-severity active alert. Shows the top 5 clients by alert count descending.

Rendered by renderPlatforms(platforms). A card per security platform showing icon, name, event count, and an Online/Degraded/Offline status pill. The status pill is green for 'ok', amber for 'warn', and red for 'err'.

Rendered by renderTimeline(timeline). A vertical timeline of recent threat events with severity color coding, HH:MM timestamp, event description, and client name. Items are displayed most-recent first. The timeline wraps in a .timeline CSS class that draws a vertical spine line down the left side.

Five KPI tiles rendered by renderWorkloadKPIs(kpis). All five source from ConnectWise PSA in production.

Rendered by renderEngineers(engineers). A four-column table: engineer name, open ticket count, a visual capacity bar, and a status badge. The capacity bar fills to Math.min(pct, 100)% — it caps visually at 100% even if overloaded, but the percentage label shows the real value.

Rendered by renderAging(aging). A four-bucket bar chart showing ticket age distribution. Each bar fills proportionally to its count relative to the max bucket. Colors: 0-2h green, 2-8h yellow, 8-24h orange, 24h+ red.

The label field must match exactly one of the four values above — the aging renderer references label==='24h+' directly when computing the KPI Aged 24h+ value.

Rendered by renderClientWorkload(clients). A five-column table: client name, open count, high-priority count, stale (24h+) count, and a 7-point SVG sparkline of the client's ticket trend over the past 7 days.

Rendered by renderVolumeTrend(weekTrend). A two-line SVG area chart (hand-drawn, no Chart.js dependency) showing opened vs closed tickets per day over the current week. Blue line for opened, green for closed, with gradient fill areas. Day labels render along the bottom axis.

Rendered by renderThroughput(kpis, weekTrend). Shows the weekly closed/opened ratio as a large percentage with color coding (green ≥90%, yellow ≥70%, red below 70%), plus two horizontal bar gauges for total opened and total closed with their raw counts.

The percentage is computed client-side: Math.round(closed/opened*100) where closed and opened are the sums of weekTrend.closed and weekTrend.opened arrays. The proxy does not need to compute this — just provide accurate arrays and the render function handles it.

Your proxy must return objects matching these shapes exactly. Field names are hardcoded throughout all renderer functions.

Your proxy's GET /api/security handler must fan out to all security vendors, normalize the results to the shapes in Section 17, and return a single JSON object. Build incrementally — start with SentinelOne and ConnectWise, let the others fall back to mock until ready.

• 1
  SentinelOne threatsCall GET https://<instance>.sentinelone.net/web/api/v2.1/threats?resolved=false&limit=20 with Authorization: ApiToken <token>. Map each threat to the threat object shape: threatInfo.threatName → type, agentDetectionInfo.agentComputerName → host, agentRealtimeInfo.accountName → client, threatInfo.confidenceLevel → severity.
• 2
  Huntress incidentsCall GET https://api.huntress.io/v1/incident_reports?limit=10 with Basic auth (base64 apiKey:apiSecret). Map each incident: summary → type, agent_name → host, organization_name → client. Huntress uses critical/high/low — map low to medium in your proxy.
• 3
  FortiGate eventsCall GET https://<fortigate-ip>/api/v2/log/disk/ips?rows=50 and /api/v2/log/disk/traffic?rows=100 with Authorization: Bearer <token>. Group by srcip and type. Map FortiGate level field: emergency/alert/critical → critical · error → high · warning → medium · information → low.
• 4
  Cisco UmbrellaFirst call POST https://api.umbrella.com/auth/v2/token with client credentials to get a bearer token. Then call GET https://reports.api.umbrella.com/v2/activity?limit=20. Map activity type to the threat/event objects. OAuth token typically expires in 3600s — cache it in your proxy.
• 5
  ESET (webhook-based)See C5. Configure ESET PROTECT to forward threat events via syslog or webhook to your proxy. Your proxy stores recent events and serves them from an in-memory store when /api/security is called.
• 6
  Aggregate and normalizeMerge all threat arrays, compute alertSummary counts by severity, build topClients sorted by alert count, compute platforms status based on each vendor's API response health, and build timeline sorted by most recent.

Your proxy's GET /api/workload handler aggregates from ConnectWise PSA only. All authentication uses Basic auth with Base64 encoded companyId+publicKey:privateKey and a clientId header.

• 1
  Engineers and open ticketsCall GET /v4_6_release/apis/3.0/system/members?conditions=inactiveFlag=false to get all active members. Then for each member, call GET /service/tickets?conditions=owner/id={id} AND status/name!="Closed"&fields=id using X-Total-Count header to get open ticket count without fetching all records.
• 2
  Ticket aging bucketsCall GET /service/tickets?conditions=status/name!="Closed"&fields=id,dateEntered with pagination. Compute each ticket's age from dateEntered and bucket into the four age ranges.
• 3
  Per-client ticket tableCall GET /service/tickets?conditions=status/name!="Closed"&fields=id,company/name,priority/name,dateEntered grouped by company/name. For each client compute open, high (priority "High" or "Critical"), and stale (age > 24h). For the 7-day trend, query tickets opened each day of the current week filtered by company.
• 4
  Weekly volume trendQuery tickets with dateEntered between [start-of-week] and [now] grouped by day for opened, and dateResolved between [start-of-week] and [now] grouped by day for closed. Return 7 values per array (Mon–Sun), with 0 for future days.

ESET PROTECT's REST API is designed for device and policy management — it does not expose a queryable threat event feed. This is not a gap in the dashboard design; it requires a different integration pattern than the other four security vendors.

To include ESET threat data on the Security page, configure your proxy as follows:

• 1
  Enable syslog forwarding in ESET PROTECTIn the ESET PROTECT console, go to More → Settings → Advanced Settings. Under Logging, enable Syslog and point it to your proxy server's IP and port. Set format to JSON if available.
• 2
  Receive and store events in your proxyAdd a UDP/TCP syslog listener to your Function App or a sidecar service. Parse incoming ESET JSON payloads and store the last N threat events in a fast store (Redis, Cosmos DB, or even an in-memory array if freshness tolerance allows).
• 3
  Serve from /api/securityWhen /api/security is called, include stored ESET events in the threats array and set the ESET platform object's status based on whether new events have arrived within the expected window (e.g. if no events in 5 minutes during business hours, set warn).
• 4
  If not using ESETRemove ESET from the platforms array in mockSecurityData() and remove any ESET entries from the threats mock array. This prevents ESET showing as "Online" with fake events in the demo view.

• ✓
  Set DEMO_MODE = false while testing. Proxy failures log to browser console only when DEMO_MODE = false. In its default true state, fallbacks are completely silent — you will see demo data with no indication anything failed.
• ✓
  Check DevTools Network tab. With DEMO_MODE = false, open DevTools → Network, switch pages, and watch the calls to /api/security and /api/workload. Confirm 200 status and valid JSON response body before checking rendered output.
• ✓
  Severity values are lowercase. All severity strings must be 'critical', 'high', 'medium', 'low', 'ok', 'warn', or 'err' — exact lowercase. Capitalized versions will produce unstyled elements with no error.
• ✓
  Aging label '24h+' must match exactly. The KPI computation uses aging.find(a=>a.label==='24h+'). If your proxy returns '24h' or '24h +' the Aged 24h+ KPI will show undefined and potentially crash the renderer.
• ✓
  weekTrend arrays must have exactly 7 items. The SVG chart uses array length to compute x-step spacing. Arrays shorter or longer than 7 will produce misaligned labels.
• ✓
  Client trend arrays must have exactly 7 items. The sparkline function also expects 7 points. Fewer produces a compressed sparkline; more produces one that overflows the SVG bounds.
• ✓
  API credentials in Key Vault, not in proxy code. Verify Function App Application Settings show Key Vault reference strings, not raw credential values.