When you need live crypto prices in an app, two technologies dominate the conversation: Server-Sent Events (SSE) and WebSockets. Both push data from the server to the client without constant polling, but they work differently and fit different apps.
This guide explains what each one is, how they differ, and which one makes more sense for price streams, alerts, and dashboards. Coinranking supports both, and both transports deliver the same JSON at the same moment. Only the connection changes. For the wider choice between a snapshot and a stream, see REST vs WebSocket for crypto prices.
What is Server-Sent Events (SSE)?
SSE is a one-way channel from server to client over a normal HTTP GET. The server answers with content-type: text/event-stream and keeps writing messages for as long as the connection stays open. In the browser you open it with EventSource. On a server, curl or any HTTP client that can read a response as it arrives is enough.
There is no subscribe message. Everything you want is in the URL. To change coins, close the stream and open a new one. EventSource reconnects on its own after a drop, and because the subscription lives in the URL, a reconnect restores the same feed.
SSE was built for feeds where the server talks and the client listens: live scores, news, price ticks.
What are WebSockets?
A WebSocket is a persistent, two-way connection. You open it once, receive updates as they are calculated, and change what you receive by sending a message, without reconnecting.
That extra direction matters when the subscription changes while the user is on the page. It is not an order channel. Coinranking’s sockets carry rates, exchange rates, and tickers, not trades or order books.
Key differences
| Feature | SSE | WebSockets |
|---|---|---|
| Direction | Server to client only | Both ways |
| Protocol | HTTP | WebSocket (wss) |
| Change a subscription | Close and open a new URL | Send a message on the open connection |
| Automatic reconnect | Built in (EventSource), after a drop | You implement it, then resubscribe |
| Missed messages | Not replayed. No event IDs | Not replayed |
| Browser support | Excellent | Excellent |
| Firewall / proxy friendliness | Very high. It is normal HTTP | Usually fine, sometimes blocked |
| Message format | The same JSON as WebSockets | JSON |
| Complexity | Low | Higher |
| Best fit | Live prices, alerts, dashboards | Watchlists that change, backend streams |
Data direction
SSE only sends data from the server. To switch coins or change the throttle, close the stream and open a new URL.
WebSockets let the client send a subscription message at any time. You can change the coin list or the throttle on the open connection.
For a fixed price ticker this difference is small. For a watchlist the user edits, the WebSocket is the cleaner fit.
Reconnection
SSE has a built-in reconnect. Coinranking sends retry: 5000 at the start of the stream, and EventSource waits five seconds after a drop and reconnects. The subscription is in the URL, so the new connection restores the same feed.
It does not resume from the last event. Coinranking sends no id: lines, so a reconnect gets the next update, not the ones you missed. A rejected request is different: EventSource closes and does not retry, and it cannot read the error body.
With WebSockets you detect the disconnect and reconnect with backoff. A subscription in the URL comes back with the same URL. A subscription you sent as a message has to be sent again.
Neither transport sends the current price when it opens. Load that from REST first.
Browser and network compatibility
SSE travels over normal HTTP, so corporate proxies rarely block it. A rejected request is a normal HTTP status with a JSON body, which is easy to debug from curl or fetch.
EventSource cannot set headers and cannot read that error body. For a production site, proxy the stream through your own server, keep the API key there, and point EventSource at your own route.
WebSockets use their own protocol. Most networks allow them. Some older proxies do not. The browser WebSocket API also cannot set headers, so the key goes on the query string.
JavaScript examples
SSE. list=all is a real subscription, and it is a high-volume stream. On a page, subscribe to the coins you show. This snippet puts the key in the query string so it runs. Do not ship that. Proxy the stream. A full page of examples is in how to stream live crypto prices in JavaScript.
const source = new EventSource(
"https://api.coinranking.com/v2/real-time/sse/rates?x-access-token=YOUR_API_KEY¤cy-uuids[]=Qwsogvtv82FCd¤cy-uuids[]=razxDUgYGNAdQ&throttle=1s"
);
source.onmessage = (event) => {
const data = JSON.parse(event.data);
console.log(data); // confirmation first, then rate messages
};
source.onerror = () => {
// A dropped connection retries on its own.
// A rejected request closes and does not retry.
};The same stream from a server, with the key in a header:
curl -N "https://api.coinranking.com/v2/real-time/sse/rates?list=all" \
-H "x-access-token: YOUR_API_KEY"WebSocket:
const ws = new WebSocket(
"wss://api.coinranking.com/v2/real-time/rates?x-access-token=YOUR_API_KEY"
);
ws.onopen = () => {
ws.send(JSON.stringify({
currencyUuids: ["Qwsogvtv82FCd", "razxDUgYGNAdQ"], // BTC and ETH
throttle: "1s"
}));
};
ws.onmessage = (event) => {
const data = JSON.parse(event.data);
console.log(data);
};
ws.onclose = () => {
// Reconnect with backoff, then send the subscription again.
};throttle is 1s or 10s, per coin. One connection takes at most 100 UUIDs.
Which to use
Use SSE when:
- You mainly need one-way price updates or alerts.
- You want the smallest client, with reconnect built in.
- You are building a public page or dashboard that displays a fixed set of prices.
Use WebSockets when:
- The user changes the watchlist and you do not want to drop the connection to do it.
- A backend holds one connection and resubscribes as jobs come in.
- You already have reconnect and resubscribe code.
Many apps use SSE for the public price strip and a WebSocket only where the subscription changes.
How Coinranking supports both
Both options come from the same API, with the same messages at the same moment:
- Server-Sent Events for a one-way price stream.
- WebSockets when the subscription has to change on the open connection.
https://api.coinranking.com/v2/real-time/sse/rates
wss://api.coinranking.com/v2/real-time/ratesTopics are rates, exchange rates, and tickers. Load the current price and history over REST, then switch to either transport for the live feed. Neither transport replays messages you missed.
Both are billed the same way: one connection costs one API call, however long it stays open and however many prices arrive.
Authentication, throttle, and subscription options are in the real-time documentation, the SSE docs, and the WebSocket docs.
Bottom line
SSE is the simpler choice for most live price displays. WebSockets are the better choice when the subscription changes without a reconnect. The messages are the same, so you can use each where it fits.
Start with SSE if you just need prices on screen. Reach for WebSockets when the app has to change what it listens to. The rest of the setup, including polling versus streaming, is in the complete guide to real-time crypto price streaming. Still choosing a provider? See the best crypto price streaming APIs in 2026.
Both transports are on the Professional plan, free for 30 days. Get your key at coinranking.com/api.




