Realtime scoring & WebSockets vs HTTP

Where to go in the product

• Primary route: /scoring/realtime-scoring (canonical; legacy /realtime-scoring redirects here).
• Relationship to main scoring: Main flow at /scoring/credit-scoring is typically request/response via HTTP. Realtime views subscribe to server push when enabled so operators see score refresh, queue position, or model output without manual reload.

WebSockets vs polling

Mechanism	When it appears	Operator expectation
WebSocket	Realtime scoring page (or embedded widgets) when tenant + gateway allow live channel	Numbers update in place; connection icon shows connected / reconnecting
HTTP polling / refetch	Fallback when sockets disabled, mobile restrictive networks, or feature flag off	User taps Refresh or waits for interval refetch-may lag seconds

Trusting the numbers (power users)

• Treat timestamp on the score card as source of truth for freshness.
• If WebSocket disconnected, assume data may be stale until reconnect-do not approve high-risk cases on stale tiles.
• Verify lab: Open realtime view, trigger a new score from another session or batch job-confirm UI updates without full page reload when sockets are on.

Integration lead notes

• Token: Same access token family as HTTP; do not log token in client-side analytics.
• Correlation: Prefer request IDs from gateway responses when correlating WS events to audit rows.

---

Back: Credit decisioning overview · Next: Risk & modeling