Quickstart notes
Why you should not call the odds API from the browser
A browser app cannot hide an API key. Every visitor can read it, and one leaked key is every rate limit and every alert stream at a stranger's mercy.
The question comes early in every web project: can the page fetch odds from the API directly? The answer is no, and the reason is one sentence long. Anything your browser sends, every visitor can read, including your key. The fix is a small server between the page and the API.
The browser keeps no secrets
The API authenticates with your key in the x-portal-apikey header, or as a query parameter for the streaming endpoints, as the site's quickstarts show. Either way, the key travels with the request. In a browser, the request is right there in the developer tools of anyone who opens your page: the header, the URL, the key.
A key in the wild is not a minor leak. It is your polling allowance spent by someone else's loop, your drop stream held open from a machine you do not own, and no way to tell their traffic from yours in your logs.
What happens when the key leaks
The damage is quiet. Your polls start hitting the ceiling because a stranger's script spends the same allowance. Your alert stream closes because a second connection with your key evicts yours. Nothing in the API misbehaves; it is doing exactly what a valid key asks, for someone else.
Rotating the key helps only after the leak stops, and it does not stop until the key is out of the page.
The shape that works: your server in the middle
The pattern every quickstart on this site already uses is the answer. The Python quickstart reads the key from an environment variable on your machine, and it never touches a browser. For a web app, the same boundary holds: your page calls your own backend, your backend calls the API with the key, and the key never leaves the server.
That backend can be twenty lines: one endpoint that fetches the board, trims it to what your page needs, and answers from its own copy with its own freshness note. The curl quickstart is enough to prototype it, because the backend is just the same two calls, server-side.
The exception that is not one
A public demo with a throwaway key on a free tier is still a leak; it just leaks a smaller allowance. If you would not paste the key into a public chat, do not paste it into a public page. The rule is the same at every size of project.
Server holds the key, page holds nothing. That one boundary is the whole security model this API needs.