What does a news story look like once it becomes a row?

You have read financial news your whole life as prose: a headline, a source, some paragraphs. A news API hands you the same story as a record with named fields, and the difference is not cosmetic. Once a story is a row you can join it to prices, count it, filter it, and get it wrong in ways that are impossible on a web page.

The anatomy of one item

/news returns an array of objects. Here is one real item, fetched with s=AAPL.US over 2026-01-05 to 2026-01-06, with the article body abbreviated:

date:      2026-01-06T23:15:00+00:00
title:     BitMEX lanza Equity Perps para trading de acciones 24/7
link:      https://www.globenewswire.com/news-release/2026/01/06/3214202/...
symbols:   [AAPL.US, AMZN.US, META.US, NVDA.US, TSLA.US]
tags:      [CRYPTO-DERIVATIVES, EQUITY-DERIVATIVES, PERPETUAL-SWAPS,
            PRODUCT / SERVICES ANNOUNCEMENT, TRADING-PLATFORM, US-EQUITIES]
sentiment: {polarity: -0.273, neg: 0.012, neu: 0.978, pos: 0.010}
content:   (the full article text, several thousand characters)

Seven fields, and each one is a different kind of claim:

• date — when the source stamped the item, as an offset-aware timestamp. The single most consequential field in the whole object, and Lesson 4 is about nothing else.
• title and content — the text. content is the article, not a summary.
• link — the source URL. It is unique per copy of the story, which makes it the natural key for deduplication and a poor key for "this event".
• symbols — the instruments a tagger associated with the item.
• tags — topic labels, stored uppercase.
• sentiment — four numbers produced by a model. Unit 2 takes them apart.

What the example already teaches

Read that item again. It is in Spanish. It is about a crypto exchange launching a derivatives product. Apple appears in it because Apple is one of ten underlyings named in a product list. And yet it arrived in a query for Apple news, carrying AAPL.US in symbols and a sentiment score attached to the whole thing.

Nothing malfunctioned. The tagger did exactly what taggers do: it found the entity. Whether "found the entity" means "this article is about that company" is your problem, not the API's — and it is the first thing you should measure on your own sample rather than assume.

Asking for it

The request parameters are short. You must supply either s (a ticker such as AAPL.US) or t (a topic tag) — one of the two is required. Then from and to as YYYY-MM-DD dates, limit between 1 and 1000 with a default of 50, offset from 0 with a default of 0, and fmt=json.

One warning before you go wide: content carries the full article. A request with limit=1000 can return several megabytes for a single call. Ask narrowly and page, rather than pulling a year of a busy symbol in one request and then wondering why your process died.

Try it now

1. Here is /news for s=AAPL.US over a single day, 25 September 2026, the newest items first; the first three carry their titles. Read the dates and titles. Three lines tell you more about the shape of the feed than the documentation does. The second table is the same call with no dates, as it stood at the last refresh.

2. For the three newest items of that day, len(content) was 5,594, 5,188 and 5,587 characters; across all 33 items of the day the average was 3,954 (measured 28 September 2026). Multiply each average by 1,000 and you have two estimates of a limit=1000 response. Say which one decides how you page, and why.
3. For each of the three titled items, answer one question by hand: is this article about Apple, or does it merely name it? Do that for thirty items and you have your own precision estimate for the symbol tagger, which is worth more than anyone's assurance.