Company News API: Press Releases Without the Newswire Contract

Searching for a press release API usually turns up the newswires, and they are selling the opposite thing. PR Newswire, Business Wire and their peers are distribution: you pay them to put your announcement in front of journalists. If what you want is to read what has been published about a company, that is monitoring, and it is a different product.

This is about the monitoring half. Monid is the OpenRouter for agent tools, so the endpoint below sits on the same key as the company resolution that has to happen first.

Fair disclosure: you are on the Monid blog. The section near the end names where a dedicated media-monitoring platform is the right buy, and it is not a short list.

Is there an API for press releases without a newswire contract?

Yes, for reading. Not for publishing, and the distinction is the whole first decision.

Distribution puts your release on the wire and into the syndication network that follows. That is what a newswire contract buys, it is priced accordingly, and no read API substitutes for it.

Monitoring returns what has been published, by anyone, about a company or a topic. That is a data problem, and akta /v1/news does it:

monid inspect -p akta -e /v1/news
monid run -p akta -e /v1/news --query '{"company":"https://canva.com"}'

One thing about the input is worth knowing before you build: a bare company name is not accepted. The endpoint takes a website or a company uuid, so a name has to be resolved first. That resolution is free:

monid run -p akta -e /v1/company/search --query '{"query":"canva"}'

Which makes the working shape a two-step: resolve the name to a company, then watch it. We covered the resolution half in finding a company's website from its name.

The endpoint also takes a query for open-ended themes, a title match, and an industry filter that resolves against a taxonomy of tens of thousands of industry codes. So it is not only a company watcher: "FDA drug approval" or a commodity movement are equally valid inputs, which matters if your signal is a market rather than an account.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-key> -l main

What does a company news record actually contain?

Twenty-seven fields, and the analysis you would otherwise build is already in them.

We ran one company query on 2026-08-17 and read a record end to end. The obvious fields are there: title, url, publisher, published date, author, full text. These are the ones that change what you build:

ai_summary is a written summary of the article, in the record. If your pipeline was going to send each article to a model for summarisation, that step is already done and paid for.

sentiment and sentiment_score arrive as a label and a number. Same argument: the classification pass you were planning has happened.

is_press_release separates a company's own announcement from independent coverage. This single boolean is the difference between measuring what a company said and measuring what the press said about it, and treating those as one number is the most common error in media reporting.

is_opinion and is_breaking do the same job for two other categories that should never be aggregated together.

naics_codes, sic_codes, iptc_codes, iab_categories put every article into four standard taxonomies at once. If you are joining news to a CRM segmented by industry code, the join key is in the record.

newsworthiness_score ranks the article's significance, which is what you sort by when a query returns more than a person can read.

entities and company_mentions list what the article actually names, which turns out to matter more than it sounds.

Why does a company query return articles that look unrelated?

Because it matches on mention, not on subject, and those diverge more than you would expect.

Here is the mistake, because we made it. Our first look at the results included an article titled "Dog vacation checklist: 10 things to do before you leave", returned for a query about a design software company. That looks like a broken relevance filter, and the obvious conclusion is that the endpoint is noisy.

It is not. Every one of the ten articles genuinely referenced the company: that one names it as a tool for making a pet-care document. Ten out of ten were correct matches and most of them were not about the company at all.

That is the actual shape of company news monitoring, and it is not a defect to be filtered away at the source. A mention in a listicle is real evidence of surface area. It is just not coverage, and if you are reporting on how a company is being written about, mixing the two produces a number that goes up when nothing happened.

The fix is downstream, and the fields for it are already in the record:

Sort by newsworthiness_score rather than by date. The article that matters and the article that mentions you in passing arrive in the same response, and recency does not separate them.

Split on is_press_release. A company's own announcements and what others wrote are two series. Reported as one, a busy PR month reads as momentum.

Check company_mentions for position. An article naming twenty companies is a roundup. One naming two is about a relationship.

Use the taxonomy codes to detect off-topic mentions. An article coded to an industry unrelated to the company is a passing reference, and that is a rule you can write once rather than reading every row.

The general lesson, which applies beyond news: when a search returns something surprising, check whether it is wrong before deciding it is. We nearly wrote that this endpoint had a relevance problem. It had a vocabulary problem, and the vocabulary was ours.

📖 See also building a company news watcher for the scheduled version of this.

Why one source is never enough for company news

The uncomfortable part of monitoring: coverage of a given company is uneven across providers in ways that do not average out.

Trade publications, regional press and non-English sources are where the differences live. A feed strong on US technology media can be thin on European manufacturing trade press, and the gap is invisible from inside the feed: you see articles, so it looks like it is working.

Three consequences worth designing around:

Absence proves nothing. A quiet week may be a quiet week or a coverage gap, and no field distinguishes them. Any alert built on "no news" as a signal is unreliable in a way that never announces itself.

Language skews the sentiment. The measured record carried an original_language field, which is there because feeds are not evenly multilingual. Aggregate sentiment across a company with heavy non-English coverage measures the English-language subset.

Syndication inflates counts. One wire release republished across twenty outlets is twenty articles and one event. The is_press_release flag plus the group_id in the record are what let you collapse them, and skipping that step is what makes coverage graphs spike on days nothing happened.

We wrote up the multi-source version of this argument in why one vendor cannot cover company news. For the scheduled implementation rather than the ad-hoc query, the company news watcher is the working build, and pulling company data on a schedule is the firmographic half of the same job.

Which endpoint should I use for which job?

Verified present on 2026-08-17 with monid discover. The billing column gives the shape rather than a figure; monid inspect prints the current figure for free.

The shape to plan around: news bills per result plus a flat fee per run, so a daily watch across many companies is many small runs, and the flat fee is paid on each. Batching companies into fewer, larger runs costs less than looping one call per account.

When should you not use Monid?

You want distribution. If the job is getting your announcement published, buy a newswire. This endpoint reads; it does not place.

You need guaranteed coverage of a specific publication. A monitoring dataset covers what it covers. If a single trade publication is the one that matters to your industry, check it is in there before building on it, and consider a subscription to that source.

You need alerting infrastructure. Dedicated monitoring platforms ship dashboards, share-of-voice reporting, alert routing and a UI for a comms team. We ship an endpoint. If the consumer is a communications department rather than a pipeline, buy the platform.

You need legal-grade archives. Litigation and compliance want completeness and provenance guarantees that a commercial monitoring feed does not offer.

And the caution about us. Metadata in this catalogue has disagreed with real behaviour before, including an endpoint that returned empty commercial fields at full price. Run one small query, read the fields and the charge, then scale.

Conclusion

Press release APIs and company news APIs sound like the same product and sit on opposite sides of the transaction. One is distribution and is sold by the newswires. The other is monitoring, and it is a data problem with a per-call answer.

Two things matter more than the endpoint. A mention is not coverage, and a query that correctly returns ten articles naming a company may return only two that are about it, so the split has to happen in your code and the fields for it are already in the record. And the analysis you were going to build is largely already there: summary, sentiment, significance and four taxonomies arrive with the article, which changes the pipeline from "fetch then process" to "fetch then filter".

Start with the free part: company resolution costs nothing, and monid inspect shows the news schema before you spend. Then run one company and read ten articles properly before deciding what the query is doing. Begin at monid.ai.

FAQ

Last updated August 2026.