API Overview: REST vs. WebSockets, Authentication, and Rate Limits
Market Reader delivers its data to enterprise clients primarily through its API infrastructure, serving as the foundational layer for brokerages, trading platforms, and institutional compliance teams.
Choosing Your Connection: REST vs. WebSockets
While both protocols are fully supported, developers must choose the correct connection type based on their specific use cases to avoid unnecessary latency and database strain.
- The WebSockets API (Recommended for Real-Time Streaming): For clients needing live, push-based market updates, WebSockets is the optimal connection. A crucial advantage of the WebSockets API is that it publishes analysis in true real-time, immediately after the 10-minute analytical window concludes.
- The REST API (Recommended for Targeted Lookups): The REST endpoint is available and well-documented, but it is best utilized for historical lookups or querying specific, targeted symbols. Developers are strongly cautioned against using the REST API for high-frequency, full-market polling. For example, querying the daily REST endpoint for all symbols every minute forces the system to compose massive amounts of data, which takes roughly 12 seconds per call and puts significant strain on the backend database and API pods.
Authentication and Token Management
Authentication for the API is handled securely via Supabase.
Caching Best Practices & Rate Management Because Market Reader provides a massive volume of data across tens of thousands of assets, client-side caching is a strict best practice.
- Many of Market Reader's most successful enterprise clients consume the data feed via WebSockets and immediately cache it locally within their own environments.
- Serving data to end-users from a local cache drastically reduces the load placed on Market Reader's REST endpoints, prevents latency spikes, and ensures high availability for the client's platform.