Building with the API — single gateway

Recommendation: route everything through the Provider

Use the Provider as your only API gateway. The Provider already aggregates data (accounts, orders, candles, connectors, detectors, inspectors) and streams events over WebSocket. Proxying Advisor, Inspector, and Detector through the Provider gives you:

1. Single entry point — One origin, one base URL
2. Single authentication — One API token (Bearer or x-api-token)
3. Simpler CORS — No need to expose ports 8008, 8009, 8101 to the browser
4. Single WebSocket — All real-time events already flow through Provider /ws

How it works

The Provider proxies requests to Advisor, Inspector, and Detector by appKey. Targets come from the Provider App Registry and are considered active when heartbeat is recent. You always call the same Provider base URL and use paths like /api/advisors/:appKey/..., /api/inspectors/:appKey/..., /api/detectors/:appKey/....

Proxy paths (quick reference)

Examples:

• GET /api/inspectors/inspector/inspector/risk/dashboard
• GET /api/advisors/advisor/advisor-agent/health
• POST /api/detectors/detector/risk/close-position

Your front-end uses a single base URL (e.g. http://localhost:8080/api for REST and http://localhost:8080 for WebSocket with path /ws). No direct calls to Advisor, Inspector, or Detector URLs from the browser.

What stays on the Provider only

• WebSocket — Centralized at Provider /ws; events from Advisor, Inspector, and Detector reach the bus and are forwarded to clients by the Provider bridge.
• REST data — Accounts, orders, candles, connectors, app registry — only the Provider serves these.
• Proxy — All calls to Advisor, Inspector, and Detector go through the Provider.

Summary

For full endpoint lists, see Provider API reference, Detector API, Inspector API, and Advisor API.