Do you ask for news by symbol, or by topic?

/news accepts two mutually exclusive ways in, and they answer genuinely different questions. s takes a ticker and means "what was written about this instrument". t takes a topic tag and means "what was written on this theme". You must send one of them; sending neither is an error.

The two universes, side by side

A symbol query for s=AAPL.US over 2026-01-05 to 2026-01-06 returned articles you would expect: Apple product coverage, a valuation argument about Tesla that mentions Apple, a crypto exchange listing Apple among its underlyings.

A tag query for t=technology over 2026-01-06, limit=1, returned this instead:

date:    2026-01-06T23:01:00+00:00
title:   Niterra Co., Ltd. Participates in $9M Growth Financing Round for Sibros
symbols: [NGK.F, NGK.MU, NGKSY.US]
tags:    [AUTOMOTIVE, MOBILITY, SOFTWARE-DEFINED-VEHICLES, TECHNOLOGY]

A Japanese spark-plug manufacturer, quoted on Frankfurt, Munich and as a US depositary receipt, investing in a software-defined-vehicle platform. No mega-cap anywhere in sight. That is the point of a topic query: it surfaces the instruments you were not already thinking about, which is precisely what a symbol query structurally cannot do.

Note also that I asked for technology in lower case and the item came back tagged TECHNOLOGY. The input is forgiving about case; the stored vocabulary is upper case. If you build a tag whitelist, normalise before comparing.

One tag per request

There is no "any of these tags" syntax. t takes a single topic, so a five-theme sweep is five requests. Combine that with the daily quota arithmetic from the API Foundations course before you design a nightly job around it.

There is also no documented way to ask "which tags exist". The practical route is to collect the tags arrays off a sample of items you already have and build the vocabulary from observation — which is honest work, and worth doing once rather than guessing at tag names in production.

Paging, and the moving-target problem

limit (1–1000, default 50) and offset (from 0, default 0) are the pagination controls. The endpoint does not document a sort parameter, and the items I received came back newest-first.

That combination has a sharp edge. If you page a live feed by incrementing offset while new articles are being ingested, every new arrival at the top shifts everything down by one, and you will see some items twice and miss others entirely. The robust pattern is to page by date window — request one day, or one hour, at a time with from and to. A closed publication window still gains items while the crawler catches up, as the next lesson explains, so leave the window a lag behind now and offset paging inside it is safe.

How far back it goes

EODHD documents news history as starting around March 2021 in general, with the major names covered back to 2018. That is a documented figure rather than one this course verified, and it matters more than it looks: a study whose window predates the coverage will silently find "no news" on days that had plenty. Always check the earliest date your own query actually returns before you conclude anything from an empty result.

Try it now

1. Here is the same day, 25 September 2026, asked both ways on 28 September. Work out what share of each set the overlap is.

Then say what a study built on only one of the two queries would never have seen. The overlap is usually much smaller than people expect. 2. The tags arrays of those 33 Apple items held 105 distinct values. The most frequent were TECH (12 items), EARNINGS (9), AI (8), REVENUE GROWTH (5), SEMICONDUCTORS (5), PRICE-TARGET (4) and PRICE TARGET (3). Find the pair in that list that a whitelist would have to merge, and say what it tells you about building a tag vocabulary from observation. 3. Here is one busy symbol, s=AAPL.US, paged through the closed week of 21 to 25 September 2026 two ways on 28 September.

No difference. Say why a window three days closed did not move, and which window the moving-target problem would have hit.