What actually happens when you ask a server for a stock price?

You have already used an API today, hundreds of times, without calling it that. Every time your browser loaded a page, it sent a request to a server and got an answer back. An HTTP API is the same machinery pointed at a different audience: instead of returning a page designed for a human eye, it returns data designed for a program.

That is the whole idea. A web page is an answer formatted for reading. An API response is an answer formatted for computing.

One question, one answer, no memory

A request is a single, complete question. You send a URL; the server sends back a status code and a body; the conversation ends. The server does not remember you between requests, which is why every single call has to carry everything it needs — including who you are.

Here is a real one, with the token replaced by a placeholder:

https://eodhd.com/api/eod/AAPL.US?from=2026-07-20&to=2026-07-24&fmt=json&api_token=YOUR_TOKEN

Before you run anything like it, one rule, because this is the first moment you could get it wrong. Your token goes in a terminal, never in a browser address bar. Authentication here is a key carried in the URL, so a key in a URL is a key in a log — browser history, sync across your devices, extensions, proxy and server logs, referrer headers, screenshots. The next lesson explains the mechanism; the rule comes first because the mistake comes first. Use curl with the token in an environment variable, and the key stays out of the browser-side ones — history, sync, extensions, referrers, screenshots. Be clear about what it does not fix: the key is still in the URL, so the API's own access log and any proxy that records full URLs still see it. That is a property of key-in-URL authentication, not of your client:

export EODHD_API_TOKEN=...        # once, in your shell
curl "https://eodhd.com/api/eod/AAPL.US?from=2026-07-20&to=2026-07-24&fmt=json&api_token=$EODHD_API_TOKEN"

Run on 2026-07-28, that returns five rows. Here are two of them, exactly as they came back:

{"date": "2026-07-20", "open": 333.51, "high": 333.71, "low": 323.68,
 "close": 326.59, "adjusted_close": 326.59, "volume": 53468000}
{"date": "2026-07-24", "open": 321.79, "high": 334.37, "low": 321.62,
 "close": 333.02, "adjusted_close": 333.02, "volume": 47443900}

Seven fields per row: a date, the four prices that define the day, an adjusted close, and a volume. That is the raw material behind every price chart you have ever looked at — including this one, which is drawing exactly that series:

Run the same command today and five of those seven fields will be identical, because they are history. adjusted_close will not, and it will be a little lower: it is a derived column that every new dividend rewrites across the whole history, so the value above is the one that existed on 2026-07-28 and nothing else. volume on a very recent day can also be corrected after first publication. Unit 4 is about telling those two apart from an actual error — for now, just notice that a response is not one kind of thing.

The chart is not a different thing from the JSON. It is the JSON, drawn.

Five rows, and why exactly five

The range 20 to 24 July 2026 is a Monday through a Friday. Five weekdays, no exchange holiday in that week, five rows. Not one row per calendar day — one row per trading day. Ask for a Saturday and you get nothing back, and nothing is wrong.

This is the first habit worth building: when you count the rows in a response, count them against the number of trading days you expected, not against the number of days on the calendar. Unit 4 comes back to this properly, because it is the source of a surprising share of quietly wrong numbers.

The base URL

The spec documents two servers for the same API: https://eodhd.com/api as the primary path and https://eodhistoricaldata.com/api as an alternative. Everything after that — /eod/AAPL.US — is the part that says what you want.

Try it now

1. The curl command above is the whole call, and two of its five rows are printed under it. When you hold a key of your own, put it in an environment variable and run exactly that: curl is just a very plain client. Note that the answer arrives as text, not as a page, and that your key never reaches your browser history.
2. Here is the same call with to moved to Saturday 25 July. Count the rows. The second table opens the window on 1 January 1970 and closes it at the end of 1980: read its first date, and say what the API did with the ten years before it.

3. Open your browser's developer tools, load any financial website, and watch the network tab. Most of what you see is the same act you just performed by hand — and notice that every key those sites use is sitting in that panel, visible to anyone who opens it. That is why yours stays server-side.

Build it yourself

Now make that request from an application, with the key somewhere the browser cannot reach it. Why your API key must never reach the browser