cryptocurrency.cv: A Keyless Crypto News API You Can Query With One cURL

What cryptocurrency.cv solves, and who actually needs it

Pulling crypto headlines usually means subscribing to a handful of RSS feeds, deduplicating them, normalising dates, and then writing the same parser again for every new source. The repository at nirholas/cryptocurrency.cv collapses that work into one HTTP call. The README describes 300+ RSS feeds across 21 categories plus 77 international outlets, exposed through 450+ routes that all return JSON and are CORS-enabled. There is no API key, no signup and no rate-limit paperwork for the hosted service.

The audience is narrow and specific. It fits someone building a Telegram bot, a Discord summariser, a LangChain tool or a dashboard who wants headlines now rather than a feed-ingestion pipeline. It also fits an AI agent that needs a tool call returning structured news, which is why the repository ships AGENTS.md, SKILLS.md, llms.txt and an MCP server. It does not fit a trading system that needs sub-second exchange data. This is news aggregation with a historical archive, not a market data feed, and the README never claims otherwise.

How the aggregation pipeline is put together

The hosted service is a Next.js application. The Dockerfile builds it with pnpm and next build in standalone output mode, then runs node server.js as an unprivileged nextjs user on port 3000. The docker-compose.yml puts an nginx:1.27-alpine container in front on port 80 for rate limiting, response caching and request coalescing, and scales the app with docker compose up --scale app=4. The app container reads REDIS_URL=redis://redis:6379, so Redis is the shared cache layer between replicas.

On the data side, the README states the feeds are tiered by credibility and that international sources support on-the-fly translation. A historical archive of 662,047 articles from September 2017 onward is searchable by date, ticker, sentiment and full text. Every response carries the same envelope: an articles array with title, link, description, pubDate, source and timeAgo, plus totalCount and fetchedAt. That fixed shape is the real product. You can swap one source for another without touching your parser.

The AI routes are a separate layer. The .env.example is explicit that GROQ_API_KEY gates /api/ask, summaries, sentiment and translation, and that without it those routes return "not configured" while every other endpoint keeps working. Other providers (OpenRouter, OpenAI, Anthropic, HuggingFace) are listed as fallbacks. So the default deployment is a plain aggregator; the LLM features are opt-in.

Installing and making a first real request

The fastest path is the hosted API, and the README gives these examples directly. This fetches the latest headlines from every source:

curl https://cryptocurrency.cv/api/news

The response is JSON with an articles array, a totalCount and a fetchedAt timestamp. If you want to narrow it, the README shows category and limit as query parameters:

curl "https://cryptocurrency.cv/api/news?category=defi&limit=20"

For a time window rather than a category, the breaking endpoint returns only the last two hours:

curl https://cryptocurrency.cv/api/breaking

From TypeScript, the README documents a package install and a two-line call:

import { CryptoNews } from '@nirholas/crypto-news';
const news = await new CryptoNews().getLatest(10);

To run the whole stack yourself, the .env.example gives a three-step zero-config path. Copy the file, install, start:

cp .env.example .env.local
pnpm install && pnpm dev

Open http://localhost:3000. According to .env.example, news, markets, archive and widgets all work with every value left blank; only the AI routes need a key. For a container deployment, docker-compose.yml exposes nginx on port 80 and scales the app service with docker compose up --scale app=4; the app healthcheck hits http://localhost:3000/api/health.

Where the source-available licence bites

The README's front matter says license: source-available (all rights reserved), hosted API free to use, and GitHub reports the licence as NOASSERTION. That is not an OSI-approved open source licence, and the repository description's own use of "open source" is looser than the licence file supports. Read LICENSE before you plan anything around the code.

In practice this splits the project in two. Calling the hosted endpoints is described as free, and the README sets no key requirement, so a prototype, a bot or an internal dashboard can call it today. Reusing the Next.js code, the widgets or the SDK sources inside your own product is a different question, and the repository does not answer it. The SDK clients in sdk/ are described as copy-in source, which is exactly the case where a permissive licence would normally matter. If redistribution or commercial reuse of the code is on your roadmap, treat the licence as an open item rather than a settled one.

The limitations that decide whether this fits

The first constraint is upstream dependence. The hosted API is a single endpoint operated by the project. The README documents no SLA, no uptime commitment and no status page, so a consumer that hard-codes cryptocurrency.cv inherits whatever availability that deployment has. Self-hosting removes that risk but replaces it with the operational cost of running Next.js, Redis and nginx and keeping 300+ feed parsers working as sources change their markup.

Second, the AI features are not self-contained. /api/ask, summaries, sentiment and translation depend on an external provider key, and the .env.example names Groq as the default. That means a self-hosted instance with no key silently degrades: those routes report "not configured" rather than failing loudly, which is easy to miss in an agent loop.

Third, the surface is very wide. 450+ endpoints and 89 pages is a lot of code to audit and upgrade, and the repository carries a long tail of integrations (Alfred workflow, ChatGPT plugin, Copilot extension, browser extension, Storybook, observability and scale compose files). If you only need headlines, you are adopting far more than you need. The narrow alternative is to subscribe to a handful of RSS feeds yourself and skip the rest.

RSS versus the cryptocurrency.cv API

The obvious alternative is doing it yourself with RSS. The README notes the project itself exposes RSS 2.0, Atom and OPML feeds, so you can consume the same underlying sources with a standard feed reader library and no dependency on cryptocurrency.cv at all. The difference is where the work sits. Plain RSS gives you raw items per feed and puts deduplication, date normalisation, category mapping, credibility tiering and full-text search on you. The cryptocurrency.cv API gives you a single normalised envelope with totalCount and fetchedAt, plus search, categories, a 662,047-article archive back to September 2017, and SSE and WebSocket streaming.

A second alternative is a commercial market and news data vendor. Those typically require a key, a plan and a contract, and they bundle price data with the news. cryptocurrency.cv is the opposite trade: no key and no contract, but no price feed and no support commitment. If your application needs exchange-grade prices alongside headlines, this is the wrong tool and you should be looking at a market data provider instead.

Maintenance, upgrade cost and what to verify

The repository is not archived, and the last push was on 2026-09-14, so the project is being changed as of that date. There are no releases retrieved, and package.json shows version 1.0.10, so versioning is by package rather than by tagged release. The CHANGELOG.md at the repository root is the place to check before upgrading.

The upgrade cost is real. The build script sets NODE_OPTIONS='--max-old-space-size=8192' and CI=true, which hints at a memory-hungry Next.js build. The Dockerfile pins node:24-alpine and pnpm@10, and it copies two patch files, patch-next-write-atomic.js and patch-next-middleware-rewrite.js, that the postinstall hook requires. Patching Next.js means a major Next upgrade can collide with those patches, so pin your Node and pnpm versions and read the Dockerfile before bumping either. The compose files also carry a deploy block with explicit CPU and memory limits (1.0 CPU, 512M memory per app replica), which is a reasonable starting point but not a measured one.

Because the README documents no deprecation policy for the 450+ endpoints, treat the OpenAPI document at https://cryptocurrency.cv/api/openapi.json as the contract and diff it against your integration when you upgrade.

Editorial conclusion

Use the hosted cryptocurrency.cv API if you need crypto headlines inside an agent, bot or prototype this afternoon and can live with a source-available licence and a single upstream dependency. Do not adopt it if you need a contractual SLA, a redistribution right over the article text, or offline operation with no third-party AI provider. Before committing, open https://cryptocurrency.cv/api/openapi.json and confirm the specific routes you plan to call still exist, then run the self-host path once with docker compose up and check that /api/health reports the build you expect.

Frequently asked questions

Official sources

1. Issues
2. nirholas/cryptocurrency.cv on GitHub
3. Project website
4. README