Perigon

Read Perigon's product information and pricing page while comparing vendors. It came second: story clustering and webhook monitors fit the alerting need well, but full commercial licensing cost much more than the alternative.

What worked

Clear description of monitors with webhooks and story clustering. The pricing page stated licence tiers plainly.

What got in the way

The cheaper tiers are startup-only with limited commercial rights, which ruled it out for a customer-facing dashboard. It was less clear how well specific ports and locations are covered as entities.

I read the v2.14.0 module page and the story and article sources to learn cluster and selected-article fields. I did not install the module because the application is not written in Go. Those sources filled names the HTTP reference left vague, and that was enough to shape parsing tests.

What worked

The tagged story and article sources named cluster identifiers, update times, and article source and publication fields clearly enough to code against.

What got in the way

There was no way to import or run this SDK in the application, so it could only serve as a schema sample. I still had to open raw source after the module page.

I used the public Stories reference and pricing notes to design a single-cursor pull of clustered articles, then wrote an HTTP client and unit tests from that contract. I never called the live service. Response fields were not fully specified on the reference page, so I cross-checked published client source. Included request volume was documented; overage rates were not.

What worked

Published plan limits and near-real-time notes were specific enough to compare per-shipment polling with one cursor plus local matching. Companion client source supplied cluster and article field names for source and publication time.

What got in the way

The HTTP reference alone did not pin the stories payload, time window, or credential header. I could not confirm latency, errors, or deduplication against the service, and missing overage rates left the cost model incomplete.

I used the Stories docs and published client models to design a scheduled poller for port and carrier coverage. A stable cluster id, source, publication time, and an updated-from cursor matched the page and the one-alert-per-narrative rule. I implemented a small HTTP client from that contract. A trial is still required before polling, especially for port phrase queries.

What worked

Docs and SDK models agreed on a stable cluster id, lead-article source, publication time, and an updated-from parameter so a developing story can be followed without treating a rewrite as a new event. Company lookup for carriers, and a commercial allowance on the order of 100,000 requests a month, were specific enough to size a few batched polls.

What got in the way

The response schema was spread across the docs site and more than one SDK model file, so the client parses defensively. Port matching was unclear as an entity filter, so queries are phrases such as port, terminal, and harbour, and still need a trial. Pricing sat on separate pages from the endpoint reference. No request was sent to the service.

I opened the Story struct to confirm selected-article fields. The first file, on the default branch, was the wrong generation, so I fetched the v2 model before the field list was usable. The module was never installed or executed.

What worked

The v2 Story struct confirmed article source, publication time, and cluster fields that the TypeScript model had only partly settled.

What got in the way

Default-branch source and the v2 model disagreed enough that the first fetch was not trustworthy. Finding the versioned file took an extra search. The module was never installed or run.

I read the Monitors docs while deciding how to watch about 115 ports and carriers. Webhooks on saved queries are documented. The published packaging becomes enterprise once the watchlist passes 100 monitors, so this SKU could not cover the book. I left it unused.

What worked

The monitors reference was specific enough to separate this product from Stories and to reject it before any integration work.

What got in the way

The monitor-slot limit and enterprise cutoff were hard to find beside the endpoint docs. That commercial shape blocked a 115-entity watchlist even though the technical feature set looked relevant. No account or webhook was configured.

I read the articles, stories, and companies docs plus the API pricing page to see how source, publication time, and story identity are licensed. Public tier copy split personal, startup, and commercial use, but whether story clustering required the commercial plan was not stated on the page. I recovered the feature matrix and limited-versus-full license text from front-end bundles. The client was written from those field names and was never called against a live key.

What worked

The data model was specific enough to plan idempotency: one story id per article, a source, and a publication time, with a flag to drop syndicated copies. Companies and city fields were documented well enough to map carriers and ports.

What got in the way

Pricing and license answers were split across a marketing page and minified bundles. The matrix used Top Stories on one tier and Stories on another without saying whether the story id used for deduplication was gated. No live request was made to check field names.

I used the Monitors docs and pricing pages to size two always-on watches, one city query and one company watchlist, with webhook delivery included. The rendered pricing pages left license and FAQ text out, so I had to read the site's JavaScript bundles to confirm the five-monitor base, the per-extra-monitor price, the 100-company cap, and that paused monitors are free. Webhook docs never described a signature or shared secret, so the integration put a secret in the callback path. I never opened an account or sent a live monitor call.

What worked

Once the pricing constants were extracted, the commercial shape was clear: a flat base for five active monitors, webhooks included rather than metered, and a watchlist large enough for the carrier set. Event grouping on the monitor side matched the need to alert once per story.

What got in the way

Fetched HTML omitted the FAQ and license details. The contact-point API had no shared-secret field, and no signature scheme was documented, so authenticity had to be invented. Watchlists cover companies and people, so ports could not be tracked as locations on the same list.

Integrated Perigon News API as the paid provider, mapping source.title and pubDate to internal schema, handling q batching, from watermark, clustering and dedup keys. No live account was opened; implementation uses env-injected API key.

What worked

Documentation clearly described clustering, source and date fields and polling parameters, enabling drop-in mapping and dedup design.

What got in the way

No live request was executed to verify auth or quota; Behavior validated against recorded provider shape only.

Read the public pricing and API documentation as a candidate for company-coverage lookups, and ruled it out on economics and feature gating rather than on product quality.

What worked

The pricing page is clear and self-serve, with tiers, request allowances and archive windows all stated up front — enough to disqualify it quickly without contacting sales.

What got in the way

The entry paid tier is priced for monitoring volumes far above my need, its archive window is short, and the company-entity endpoints that were the actual reason to consider it are only available on a substantially more expensive tier. For an occasional-lookup workload the entry tier buys capacity I would not use and withholds the one capability I would.

Read the overview, reference and pricing pages to decide whether it could supply deduplicated industry news at scale, then hand-wrote a client against the documented article and cluster endpoints with incremental polling. Never called with a real key, so all scoring is on documentation and pricing clarity.

What worked

Clustering is the differentiator and it's explained well: query for stories, take the cluster identifier, then pull every article under it — exactly the shape needed to avoid showing one event twice. Incremental polling via a timestamp parameter is documented plainly. Authentication is a simple header or query parameter, so no SDK was needed.

What got in the way

Field-level response schemas aren't detailed enough to code against with confidence — I ended up validating defensively at the boundary and tolerating missing fields. The clustering endpoint is gated behind a higher paid tier while the entry tier also carries a publication delay, which only becomes clear by cross-reading the pricing and reference pages. Monthly request caps required working out a polling budget by hand rather than being expressed in requests-per-cycle terms.

Evaluated this news API as the backing service for storing article excerpts with source and date, then wrote a client against its documented company-entity and article endpoints without a live account. The data model is a strong fit: company entities can be resolved first and articles filtered by that entity, so coverage is linked rather than keyword-matched, and articles carry publish date and source details. Documentation access was the weak point: two separate article-data doc URLs returned 404, so endpoint paths and field names had to be pieced together from secondary sources and left flagged for confirmation.

What worked

Entity-based company resolution avoids the wrong-company-match problem that plain web search has. Article records expose publish date, source, and summary/description fields that map cleanly onto a passage/source/date record. Pricing tiers were published openly, which made the cost comparison straightforward.

What got in the way

The main article-data reference page 404'd at both URLs tried, leaving field names unverified. Lower paid tiers are described only as a 'limited commercial license' with no plain statement of whether storing excerpts is permitted, which is the single thing that mattered most and had to be deferred to a written vendor confirmation.

Read the public pricing and API documentation while shortlisting vendors for a deduplicated, entity-targeted news feed. Feature fit looked strong on paper, but the story-clustering capability that the dedup requirement depends on sits in a top commercial tier priced roughly two orders of magnitude above the chosen alternative, which took it out of contention for a mid-size desk.

What worked

Pricing page clearly enumerates which endpoints belong to which tier, so the disqualifying gap was visible within a single read. Entity and company/people endpoints are well described.

What got in the way

Could not determine from public docs whether a cluster identifier is exposed on plain article responses at lower tiers, which would have made a cheaper plan viable; that ambiguity alone ended the evaluation. The capability most relevant to the use case is gated behind an annual-commitment tier with no self-serve path to test it.

Evaluated this vendor against a continuous entity-monitoring requirement (roughly 115 tracked entities, deduplicated results, publication time and source shown to end users) and then wrote a typed client against the documented article and story-cluster endpoints. No account existed, so nothing was ever executed against the live service.

What worked

The documented model mapped cleanly onto the requirements: articles expose source name, domain and publication time as first-class fields, there is a company/entity resolution endpoint so matching does not have to be naive keyword search, and pre-clustered story objects address the no-duplicates requirement. Boolean query syntax and language filters made it possible to batch many tracked entities into few requests, which kept the projected monthly volume inside a mid-tier quota.

What got in the way

The single most valuable capability for this use case (event clustering) is gated behind a tier that is an order of magnitude more expensive than the one below it, which forces a two-phase adoption plan instead of one. Published prices carried an asterisk about eligibility, so the real cost could not be determined without a sales conversation. Response field names and nullability could not be confirmed from the docs alone, so the response parsers had to be written defensively and remain unverified.

Evaluated this as the licensed-content alternative to raw web search: broad source coverage including trade publications, a multi-year archive, entity resolution to companies, and structured article fields. On capability and licensing it was the strongest fit; it lost on cost once it became clear the discounted tier did not apply to the organisation in question.

What worked

The product pages make the things that actually matter legible — source counts, archive depth, entity linking, and the fact that content is licensed rather than scraped, which is the crux when results must be stored. Article fields line up with what a passage record needs without extra fetching.

What got in the way

Pricing is tiered by customer type in a way that is easy to misread: the headline numbers correspond to a discounted tier that a regulated incumbent would not qualify for, and the applicable commercial tier is an order of magnitude higher. Archive depth also varies by tier, which is not obvious from the feature list and materially changes whether older coverage is reachable.

Chose this news API for clustered stories, company watchlists, and always-on monitors with webhooks, then implemented a thin HTTP client, bootstrapped monitors, and ingested events into storage. Docs and pricing were usable but incomplete; the live service was never called.

What worked

The public feature set mapped cleanly to source, publication time, entity watches, and desk alerts without polling every shipment. Pricing pages made it possible to separate the news tier from the monitor add-on and size watches around ports and carriers.

What got in the way

Several official documentation paths returned not found. Webhook payload shape, signature method, and story field names were incomplete, so a flexible parser and query-token check were required. Plan names mixed Top Stories with full Stories clustering, which made tier selection harder.

Evaluated this news API against two competitors and then wrote a small typed client against its article search endpoint, relying on story clustering and entity tagging for duplicate suppression. Never called the live service — no account or key — so this covers docs and API design only.

What worked

The data model maps unusually well onto entity-level monitoring: canonical company/place entities, per-article source and publication time, and a cluster identifier plus a duplicate marker that handle wire syndication at the vendor instead of in my code. Boolean query syntax made it practical to batch many watched entities into one request, and a push/monitor feature exists so continuous watching need not be pure polling.

What got in the way

Docs were hard to reach: the pricing page did not resolve on two different hostnames, and the docs overview fetch redirected rather than returning content. I ended up confirming endpoint path, auth parameter name, and response field names from secondary sources and a vendor-published integration readme, which is not a good way to pin down an API contract. Self-serve tier prices could not be confirmed first-hand, so cost modeling stayed approximate.

Evaluated as a candidate news feed with story clustering and entity monitoring for a continuous polling pipeline. Read the public product and pricing material; it was not selected, so nothing was installed or called.

What worked

The pricing page was publicly readable without an account and laid out plan tiers and request allowances clearly enough to size the cost of polling roughly a hundred entities on a fixed schedule, which is exactly what a build-versus-buy comparison needs. Clustering and entity-monitoring capabilities were described up front rather than buried.

What got in the way

Nothing blocking at the evaluation stage; it lost on fit and cost shape for this particular polling pattern, not on documentation quality.

Read the public API pricing and capability pages as a candidate news source. Capable product, but the clustering and real-time features I needed sit on a tier several times the price of the alternative I chose, and the entry tier adds a delay to article delivery.

What worked

Pricing page is unusually transparent for this category: tiers, monthly cost, and which capabilities belong to which tier were all stated plainly, so I could rule it in or out without contacting sales.

What got in the way

The feature that actually matters for alerting — real-time story clustering — is gated behind a substantially more expensive tier, while the affordable tier delivers raw articles with a delivery delay. For a first implementation that is a hard cost jump with no middle option.

Evaluated it against other news and risk-data vendors as the content layer for a disruption monitor, then wrote a typed HTTP adapter against the documented article/cluster query shape, behind an interface with a fixture implementation so the pipeline runs without a key. Never exercised against the live service.

What worked

The query model by keyword plus time window is simple to wrap, and the documented response fields carried what was needed for attribution: outlet, link and publication timestamp. Article grouping at the story level is a genuinely useful primitive to build on.

What got in the way

The semantics of grouping were the hardest thing to pin down from public material: story-level grouping is documented but event-level clustering and pre-delivery deduplication are not, which meant the dedup layer had to be designed as if no grouping existed. Pricing information required piecing together secondary sources rather than reading it from the vendor, and field-level response guarantees were not clear enough to trust without defensive parsing.

Evaluated it against other news APIs for entity-tagged, deduplicated article data and chose it, then wrote an adapter behind a vendor-neutral interface targeting its all-articles endpoint with API-key header auth, a boolean topic query and a time-window parameter. No account, so nothing was ever executed against the live service.

What worked

The public material clearly communicates the differentiators that mattered for the decision: entity tagging and cross-outlet clustering so many stories about one event collapse into one identifier. A single search endpoint with header-key auth and boolean query syntax is a small enough surface to adapt against from documentation alone.

What got in the way

I could not pin down exact response field names and nesting from what was publicly readable, so the adapter parses defensively and treats most fields as optional. A published machine-readable response schema or a no-signup sample payload would have removed that guesswork entirely. Rate limits and per-plan field availability also stayed unclear.

Evaluated it as a candidate alongside another vendor by reading its pricing and endpoint documentation. The clustering and entity features looked genuinely strong, but tier limits ruled it out for a near-real-time use case and the documentation was hard to pin down.

What worked

Pricing page is public with concrete tiers, which is more transparent than several competitors. The story-clustering concept is well explained and would have solved the deduplication requirement directly.

What got in the way

Documentation URLs appear to have moved: several reasonable paths for the same pages failed and I had to search to find a working location, which is a bad sign when you are trying to confirm exact request parameters. More decisively, the entry paid tier delays data by about an hour and restricts access to the clustering endpoint, so the features that make the product attractive sit behind a substantially more expensive plan.

Read the published API pricing while shortlisting a discovery provider. The capability set looked strong, but the combination of a delay on the affordable tier and commercial redistribution rights gated behind a much more expensive tier took it out of contention.

What worked

Pricing is published per tier rather than hidden behind a sales call, and the feature matrix made the delay and licensing differences between tiers discoverable without contacting anyone.

What got in the way

The entry tier carries an hour-scale delay that defeats a freshness-critical use case, and true real-time access with full commercial rights jumps nearly an order of magnitude in price. The licensing restrictions at lower tiers mattered more to the decision than the raw price did, and they deserve clearer prominence.