The API is one door of several
Why this matters. The person asking you a question is usually not holding a terminal. Most people reach our data through something built on top of the API, and knowing which something is the difference between a useful answer and a shrug. Foundation: When is a quote lying to you?
The REST API is the foundation. Every other route in this unit is a wrapper around it, which is why understanding the door itself makes the other three easier.
Pull, and the one route that pushes
Almost everything we sell is a pull: someone asks, we answer. The exceptions are worth knowing because they are a different promise.
A pull route promises the data is available. A push route promises it arrives — the real-time stream, and alerts delivered into a chat rather than fetched. That second promise is harder to keep and harder to verify: a stream that quietly drops half a subscription looks like a market gone still, and an alert that never fires looks exactly like nothing happening.
So the client who says "I do not want to build a poller" is not asking for a different endpoint. They are asking for a different shape of product.
Two walls, and clients confuse them constantly
This is the most useful distinction in the whole unit.
- The daily call limit is a quota: how many requests a plan allows per day. Hit it and requests fail until the daily reset. This is the wall you hit by being busy all day.
- The rate limit is a speed cap: how many requests per minute are accepted. Hit it and requests bounce even with most of the day's quota untouched. This is the wall you hit by rushing — a script firing a thousand requests in a few seconds.
The diagnosis is usually in the client's own sentence. "I am blocked but I have only used half my calls" is the speed cap. "It worked all morning and now nothing works" is the quota.
The daily quota counts API calls, and a request is not always one call. The API limits page (eodhd.com/financial-apis/api-limits, read 2026-09-07) prices a fundamentals request at 10 calls, a bulk request at 100, intraday, news and technical requests at 5 each, and options and marketplace requests at 10. A client who has made 5,000 fundamentals requests has spent 50,000 calls. "I have only used half my calls" is usually a count of requests, and the wall is measured in calls. Read the account's own counter first: /user returns apiRequests beside dailyRateLimit. The daily allowance resets at midnight GMT; the counter does not, until the account's next request — read before that and it is still showing the last active day. If the counter is at the limit, it is the quota. The public lesson What a call costs prices every family.
A naming trap in our own API
The /user endpoint reports the daily quota in a field called dailyRateLimit.
Read quickly, that looks like the speed cap. It is not, and the per-minute rate
limit has no field of its own.
Which is why the vocabulary matters more than it should: say "the daily call limit is exhausted" or "the per-minute rate limit triggered". Never "they hit the limit", because that sentence contains no diagnosis at all.
A ticket usually carries a status code rather than a sentence, and three codes cover most of them. 401 means the token was missing or wrong. 403 means the token is valid and the plan behind it does not include that path; this holds on every endpoint, and a marketplace product is one instance of it. 429 means the per-minute limit, and the X-RateLimit-Limit and X-RateLimit-Remaining headers on every response show where the client stands. /user does not name the plan: subscriptionType is the billing period, and the fields beside it are the quota and today's consumption, so which paths a key may call is read from the account itself. The public lesson Errors and retries carries the full list.
Try it now
Classify each of these before reading on: a backtester pulling twenty years across five hundred tickers at nine o'clock sharp; a dashboard refreshing every symbol once a minute all day. Which wall does each hit first, and what would you tell them to change?