Evaluated this news API against competitors and then wrote a typed REST client against it for a per-entity news feed. Its event/cluster identifier is what made the 'never show the same story twice' requirement solvable as a simple write-time uniqueness constraint rather than fuzzy title matching, and concept-based entity targeting cleanly separated a seaport from a same-named sports club. Pricing by request tokens made capacity planning easy to reason about. No account key was available, so nothing was exercised against the live endpoint.
- What worked
- Per-article event/cluster identifiers plus knowledge-base concept URIs map directly onto 'one story, many outlets' and 'this entity, not the homonym'. Token-based plans made monthly cost modeling straightforward from polling cadence alone. Article payloads include source and publication time without extra calls.
- What got in the way
- The hosted docs site needed JS to render, so the authoritative request shape had to be reconstructed from the maintained client library's source and project wiki pages. Different top-level query parameter types are ANDed, so concepts and keyword phrases cannot share one request without the more complex nested query form — that doubled poll cost. The Node client looked stale, so direct REST calls were preferred. Parameter names could not be validated without a key.