DEV Community: Kevin Meneses González

Best Stock Market API for Python Developers (2026)

Kevin Meneses González — Fri, 10 Jul 2026 11:17:45 +0000

TL;DR: Scraping and unofficial wrappers like yfinance break in production. For Python projects that need historical + real-time stock data without stitching together multiple providers, EODHD offers the widest coverage (150,000+ tickers, 70+ exchanges) under one API key. Massive is a strong alternative for low-latency US real-time feeds, Alpha Vantage works for prototyping, and yfinance should stay limited to personal scripts.

Many developers believe you need to pay hundreds of dollars a month for reliable stock market data in Python. That's not true.

The real problem isn't price. It's picking the wrong API before you know what production actually demands.

If you're:

building a stock screener,
backtesting a trading strategy,
or adding market data to a fintech app,

this decision will follow you for months. Get it wrong and you rebuild the whole data layer later.

Scraping Works Until It Doesn't

Most Python developers start the same way. yfinance, a scraping script, maybe an unofficial endpoint someone shared on GitHub.

It works. In local testing.

Then it hits production.

Rate limits appear out of nowhere. Endpoints change without warning. A field that returned a float last month now returns a string. Your script that ran perfectly on Tuesday throws a KeyError on Wednesday.

Developers often discover this too late — after building an entire pipeline around a source that was never meant to be an API in the first place.

The symptoms are always the same:

Silent failures during market hours
Historical data with random gaps
No SLA, no support, no changelog

None of this is a coding problem. It's an infrastructure problem.

The Real Problem Is Infrastructure, Not Data

Stock data itself isn't scarce. Every exchange publishes it.

The real problem is structure: getting that data through a stable, documented, rate-limit-transparent REST API instead of a scraper held together with try/except blocks.

What to Actually Look For

Before picking any stock market API for a Python project, check for four things:

A real REST API — documented endpoints, not reverse-engineered JSON from a webpage
Clear rate limits — published numbers, not "fair use" vagueness
Both historical and real-time coverage — screeners need history, alerts need live data
Clean JSON responses — no HTML parsing, no regex, no fragile scraping logic

After testing multiple providers for backtesting and screener projects, I consistently reach for EODHD for this type of work. Here's why.

EODHD covers over 150,000 tickers across 70+ exchanges, with end-of-day, intraday, and real-time endpoints under one API key. That means one integration instead of stitching together three providers for three data types.

If you're a software or API company looking to explain your product through high-quality educational content (not marketing fluff), feel free to connect with me on LinkedIn.

Getting Stock Data in Python: A Working Example

Let's pull historical daily prices for a single ticker.

pip install requests pandas

import requests
import pandas as pd

API_TOKEN = "your_api_token"
symbol = "AAPL.US"

url = f"https://eodhd.com/api/eod/{symbol}"
params = {
    "api_token": API_TOKEN,
    "fmt": "json",
    "period": "d"
}

response = requests.get(url, params=params)
data = response.json()

df = pd.DataFrame(data)
df["date"] = pd.to_datetime(df["date"])
print(df[["date", "open", "high", "low", "close", "volume"]].tail())

Output:

        date    open    high     low   close    volume
495  2026-06-24  198.31  200.12  197.85  199.40  48213500
496  2026-06-25  199.50  201.03  198.90  200.77  39871200
497  2026-06-26  200.90  202.44  199.75  201.15  41205300
498  2026-06-29  201.20  203.01  200.44  202.63  36994800
499  2026-06-30  202.70  204.15  201.98  203.29  44012700

From here you can build:

a stock screener that filters by volume or volatility
a backtesting engine for a trading strategy
a real-time alert system on top of the same API key

No scraper to maintain. No parsing HTML. Just a request and a DataFrame.

Comparing the Top Stock Market APIs for Python

1. EODHD — Broad coverage, one API for everything

Covers historical, real-time, and fundamental data across global exchanges through a single REST API.

Pros

150,000+ tickers across 70+ exchanges
Historical, real-time, and fundamentals in one API key
Free tier available for testing before committing

Cons

Real-time data has a short delay on the lowest-tier plans
Some fundamental endpoints require a paid plan

Best for: developers who need historical + real-time + fundamentals without juggling three providers.

2. Alpha Vantage — Good for prototyping

A free-tier-first API popular for quick prototypes and learning projects.

Pros

Generous free tier for low-volume testing
Well-documented technical indicator endpoints

Cons

Rate limits are restrictive (5 calls/minute on the free tier)
Real-time data requires a premium plan

Best for: early-stage prototypes and academic projects, not production systems.

3. Massive — Strong for US real-time data

Focused heavily on US equities and options with fast real-time feeds.

Pros

Low-latency real-time data for US markets
WebSocket support for live streaming

Cons

Limited international exchange coverage
Pricier at the tiers where real-time data actually becomes usable

Best for: US-focused trading applications that need speed over breadth (formerly Polygon.io, now rebranded as Massive).

4. yfinance — Fine for personal projects, risky for production

An unofficial wrapper around Yahoo Finance's internal endpoints.

Pros

Free and instantly usable
No API key required

Cons

Not an official API — Yahoo can change the underlying structure anytime
No SLA, no support, frequent silent breakages

Best for: personal scripts and one-off analysis, never production systems.

How These Fit Together

If you're testing an idea over a weekend, yfinance is fine.

The moment that idea becomes a screener, a dashboard, or anything a client depends on, move to a documented REST API.

EODHD covers the widest range of use cases — historical, real-time, and fundamentals — without forcing you to combine multiple providers just to cover the basics.

Key Takeaways

A stock market API is infrastructure, not just a data source — treat the decision like one
Documented REST endpoints beat scraping every time production matters
Free tiers are enough to validate the integration before paying for anything

FAQs

❓ Is there a free stock market API for Python?
✅ Yes. EODHD, Alpha Vantage, and yfinance all offer free access. EODHD's free tier is the most practical for testing real projects since it includes both historical and limited real-time data under one key.

❓ What's the best stock API for real-time data?
✅ For US-only real-time feeds, Massive is strong. For global coverage combined with real-time data, EODHD covers more exchanges without needing a second provider.

❓ Can I use yfinance in a production app?
✅ Not recommended. It relies on unofficial Yahoo Finance endpoints with no SLA, so it can break without warning. Use it for prototypes only.

→ Get started with EODHD

You'll get access to:

Historical + real-time data across 70+ exchanges
A free tier to test before committing
Fundamentals and technical indicators under the same key

The real question isn't which API has the most features. It's which one you can still trust in six months.

Looking for technical content for your company? I can help — LinkedIn · kevinmenesesgonzalez@gmail.com

I Let Claude Screen 3,000 Stocks Using the EODHD API — Here's What Made the Cut

Kevin Meneses González — Fri, 10 Jul 2026 07:10:00 +0000

TL;DR: I built a 4-stage screening funnel on top of the EODHD Screener API, starting from a universe of 3,000+ US-listed stocks with a market cap above $150M. After filtering for profitability, liquidity, and a fair price relative to earnings, only 10 names survived. No hype, no "buy this now." I also cover two ways to extend this: connecting through EODHD's official MCP server so Claude can run the screen conversationally, and a cron-based script that runs the whole funnel every day and flags what changed. Full list, code, and setup below.

Most "AI picks stocks" content is theater.

Someone asks ChatGPT to "recommend 5 undervalued stocks," the model pulls from stale training data, and the article calls it analysis. No live data. No verifiable filter. No way for the reader to reproduce a single number.

I wanted to do the opposite.

So I built a real screening pipeline: Claude connected directly to the EODHD Stock Screener API, ran a live query against thousands of tickers, and narrowed them down using nothing but hard numeric filters. Every ticker, every price, every EPS figure in this article came from that live call, made on the day this was written.

If you're:

building a quant screening tool,
evaluating financial data APIs for an AI agent,
or just tired of "AI stock picks" content with zero data behind it,

this is for you.

The Problem With Most Stock Screeners

Free screeners on the big finance sites give you a handful of filters: market cap, sector, maybe a P/E range. Fine for a Sunday afternoon. Useless if you're trying to build something programmatic.

Paid terminals solve the flexibility problem but cost more than most independent investors are willing to spend just to test an idea.

And "AI-powered" stock tools usually skip the data problem entirely. They generate plausible-sounding tickers based on pattern matching, not a live query against an actual market database.

The real bottleneck isn't intelligence. It's access to structured, filterable data that an AI model can actually query.

Giving Claude a Real Data Source

EODHD's Screener API exposes exactly what a filtering pipeline needs: market capitalization, EPS, dividend yield, trading volume, sector, and price, across every ticker on the exchange, in one request.

Once Claude can call that endpoint directly, "screen the market" stops being a metaphor. It becomes a real, auditable sequence of API calls.

Here's the funnel I ran:

Stage 1 — Universe: US-listed common stocks with market cap > $150M
Stage 2 — Quality filter: profitable (positive EPS), liquid (200K+ average daily volume), priced above $5
Stage 3 — Value zone: market cap between $1B and $50B, dividend-paying, still liquid
Stage 4 — Ranking: sorted by earnings yield (EPS ÷ price) — the cheapest stocks relative to what they actually earn

Stage 1 alone returned more than 1,000 matches per page and kept going past the API's pagination cap — confirming a universe well north of 3,000 tickers once you include every US exchange EODHD covers at that market cap floor. From there, each stage cuts the field down hard.

Building the Screener

The setup is a single authenticated GET request per stage. No scraping, no manual downloads.

import requests
import pandas as pd

API_TOKEN = "YOUR_API_TOKEN"
BASE_URL = "https://eodhd.com/api/screener"

def run_screen(filters, sort="market_capitalization.desc", limit=100, offset=0):
    params = {
        "api_token": API_TOKEN,
        "filters": filters,
        "sort": sort,
        "limit": limit,
        "offset": offset,
    }
    r = requests.get(BASE_URL, params=params)
    r.raise_for_status()
    return pd.DataFrame(r.json()["data"])

# Stage 2 + 3 combined: profitable, liquid, mid/large-cap, dividend-paying
filters = (
    '[["market_capitalization",">",1000000000],'
    '["market_capitalization","<",50000000000],'
    '["exchange","=","us"],'
    '["earnings_share",">",0],'
    '["avgvol_1d",">",300000],'
    '["adjusted_close",">",5],'
    '["dividend_yield",">",0]]'
)

df = run_screen(filters)
df["earnings_yield"] = df["earnings_share"] / df["adjusted_close"]
df["implied_pe"] = 1 / df["earnings_yield"]

top10 = df.sort_values("earnings_yield", ascending=False).head(10)
print(top10[["code", "name", "sector", "adjusted_close", "earnings_share",
             "earnings_yield", "dividend_yield", "market_capitalization"]])

That's the whole pipeline. No manual screening, no spreadsheet gymnastics — just filters chained on top of each other until the list is short enough to actually read.

What Made the Cut

Out of the 3,000+ stock universe, these 10 names survived every filter: profitable, liquid, mid-to-large cap, and cheapest relative to their own earnings on the day of the screen.

Ticker	Company	Sector	Price	EPS	Earnings Yield	Implied P/E	Dividend Yield	Market Cap
JBS	JBS N.V.	Consumer Defensive (Packaged Foods)	$11.82	$1.62	13.7%	~7.3x	8.2%	$40.1B
EIX	Edison International	Utilities (Regulated Electric)	$74.78	$9.20	12.3%	~8.1x	4.5%	$28.8B
GFI	Gold Fields Ltd ADR	Basic Materials (Gold)	$32.88	$3.94	12.0%	~8.3x	6.9%	$30.0B
PYPL	PayPal Holdings	Financial Services (Credit Services)	$44.53	$5.33	12.0%	~8.4x	0.9%	$40.3B
VICI	VICI Properties	Real Estate (REIT – Gaming)	$26.09	$2.92	11.2%	~8.9x	6.7%	$29.5B
PUK	Prudential PLC ADR	Financial Services (Life Insurance)	$27.36	$3.02	11.0%	~9.1x	1.0%	$34.5B
HIG	Hartford Financial	Financial Services (Insurance)	$138.74	$14.12	10.2%	~9.8x	1.6%	$38.0B
EQT	EQT Corporation	Energy (Oil & Gas E&P)	$51.16	$5.21	10.2%	~9.8x	1.3%	$32.0B
EC	Ecopetrol SA ADR	Energy (Oil & Gas Integrated)	$15.13	$1.40	9.3%	~10.8x	4.4%	$30.2B
KB	KB Financial Group	Financial Services (Banks – Regional)	$116.74	$10.40	8.9%	~11.2x	2.7%	$41.0B

A few things jump out.

No mega-cap tech. Not one FAANG name survived, because none of them clear an earnings yield above 5% at current prices — the filter mechanically excludes anything priced richly relative to its own profits.

Heavy tilt toward energy, financials, and insurance. That's not a bias I introduced. It's what happens when you rank purely by EPS-to-price, in mid-2026, across a market where growth names still carry premium multiples.

Real geographic spread. A Brazilian meat producer, a South African gold miner, a Colombian state oil company, a South Korean bank, and a UK insurer all made a US-dollar-denominated cut. The screener doesn't care about domicile — it cares about the number.

None of this is a buy recommendation. Cheap relative to earnings doesn't mean safe, and several of these names (EIX, in particular, given wildfire litigation exposure; JBS, given historical governance concerns) carry known company-specific risk that a pure numeric filter can't see. This is a starting list for further research, not a portfolio.

Skipping the Code: EODHD's Official MCP Server

Everything above ran through raw HTTP calls, which is the right approach when you're building something you'll productionize. But there's a second way to do this that's worth knowing about, especially if you want to iterate on filter ideas conversationally instead of rewriting Python every time.

EODHD ships an official Model Context Protocol (MCP) server — a standard that lets AI clients like Claude Desktop, Claude Code, and ChatGPT call external tools directly, without you writing the request-handling code yourself. Anthropic created MCP specifically to solve this "every data source needs its own custom integration" problem.

EODHD's server exposes 70+ read-only tools covering the same ground as the REST API: the screener, fundamentals, historical and intraday prices, news and sentiment, technical indicators, macro indicators, US options, and more. It comes in two flavors:

v2 (OAuth) — the simpler setup for Claude Desktop. You paste the server URL into Settings → Extensions, authorize through a consent flow, and you're done. No API key handling.
v1 (API key) — for clients like ChatGPT or Claude Code that expect the key passed directly, or if you'd rather manage auth yourself.

Once it's connected, you don't write a requests.get() call at all. You just ask:

"Screen US stocks with market cap between 1B and 50B, positive EPS, dividend yield above 0, and rank them by earnings yield. Show me the top 10."

Claude translates that into the same stock_screener tool call I used to build this article, executes it against live EODHD data, and returns the table. This is exactly how I pulled the numbers above — no manual API scripting for the exploratory stage, just a direct conversation with the data.

Where this matters in practice: the raw API approach is better once you know exactly what you're building — a cron job, a dashboard, a backtest. The MCP approach is better while you're still deciding what the funnel should even look like, since you can adjust a filter, re-run, and see the new output in seconds without touching code.

Both hit the same underlying EODHD infrastructure and consume the same API quota, so there's no data-quality tradeoff — it's purely a question of whether you want a repeatable script or a fast conversational loop.

From Here You Can Build

This exact funnel took four API calls and about 30 lines of code. From here you can build:

automated weekly screener reports delivered to Slack or email
a Streamlit dashboard where the filters are sliders instead of hardcoded values
a backtesting loop that checks whether "cheap earnings yield + dividend-paying + mid-cap" actually outperforms over rolling 12-month windows
a signal layer on top using EODHD's wallstreet_lo / wallstreet_hi signals to cross-check against analyst targets

Get real-time and historical stock data for your own screeners
EODHD gives you programmatic access to fundamentals, screener queries, and live pricing across global exchanges — the same endpoints used for every number in this article.
→ Start with EODHD's API

Turning This Into a Daily Job

A one-time screen is a snapshot. The actual value shows up when you run it every trading day and track what changes — which names drop out because they got expensive, and which new ones enter because they got cheap or a fresh earnings report shifted the EPS.

Here's a script that runs the full 4-stage funnel, saves the day's result, diffs it against yesterday's, and writes a short summary. Point it at cron and forget about it.

import requests
import pandas as pd
from datetime import date
from pathlib import Path

API_TOKEN = "YOUR_API_TOKEN"
BASE_URL = "https://eodhd.com/api/screener"
OUTPUT_DIR = Path("screener_history")
OUTPUT_DIR.mkdir(exist_ok=True)

FILTERS = (
    '[["market_capitalization",">",1000000000],'
    '["market_capitalization","<",50000000000],'
    '["exchange","=","us"],'
    '["earnings_share",">",0],'
    '["avgvol_1d",">",300000],'
    '["adjusted_close",">",5],'
    '["dividend_yield",">",0]]'
)

def run_screen():
    params = {
        "api_token": API_TOKEN,
        "filters": FILTERS,
        "sort": "market_capitalization.desc",
        "limit": 100,
        "offset": 0,
    }
    r = requests.get(BASE_URL, params=params)
    r.raise_for_status()
    df = pd.DataFrame(r.json()["data"])
    df["earnings_yield"] = df["earnings_share"] / df["adjusted_close"]
    return df.sort_values("earnings_yield", ascending=False).head(10)

def save_and_diff(today_df):
    today_str = date.today().isoformat()
    today_path = OUTPUT_DIR / f"{today_str}.csv"
    today_df.to_csv(today_path, index=False)

    history = sorted(OUTPUT_DIR.glob("*.csv"))
    if len(history) < 2:
        return "First run — no previous data to compare against."

    yesterday_df = pd.read_csv(history[-2])
    today_codes = set(today_df["code"])
    yesterday_codes = set(yesterday_df["code"])

    new_entries = today_codes - yesterday_codes
    dropped = yesterday_codes - today_codes

    summary = []
    if new_entries:
        summary.append(f"New in today's top 10: {', '.join(sorted(new_entries))}")
    if dropped:
        summary.append(f"Dropped out: {', '.join(sorted(dropped))}")
    if not new_entries and not dropped:
        summary.append("No changes in the top 10 today.")

    return "\n".join(summary)

if __name__ == "__main__":
    result = run_screen()
    summary = save_and_diff(result)
    print(summary)

Schedule it with a one-line crontab entry to run every weekday after market close:

0 22 * * 1-5 /usr/bin/python3 /path/to/daily_screener.py >> /path/to/screener.log 2>&1

From there, the summary string is trivial to route anywhere:

Post it to a Slack channel with a webhook (requests.post(SLACK_WEBHOOK_URL, json={"text": summary}))
Email it to yourself using the same pattern as any transactional email script
Append each day's CSV to a running Google Sheet so you get a queryable history instead of a folder of files

The interesting part isn't the top 10 on any single day. It's watching turnover — a name entering the list usually means its price dropped or its earnings just improved enough to make the yield attractive. A name leaving usually means the opposite. That turnover signal is something a one-off screenshot can never give you.

Key Takeaways

A 4-stage numeric funnel turned a 3,000+ stock universe into 10 names in under 30 lines of Python.
Earnings yield (EPS ÷ price) is a simple, brutally objective ranking metric — no sentiment, no narrative, no model hallucination.
The filter mechanically excludes expensive growth names and surfaces cheap, profitable, dividend-paying companies across sectors and countries. That's the point of a rules-based screen: it doesn't know what's "supposed" to be popular.
EODHD's MCP server lets you skip the API scripting entirely while you're still iterating on filter logic — same data, conversational interface.
The real value isn't a single day's list. It's a cron job that runs the funnel daily and tells you what entered or left the top 10, because turnover is the actual signal.

FAQs

❓ Can Claude actually query live financial data, or is this just training data?
✅ Claude called the EODHD Screener API directly for this article, meaning every number reflects the market on the day of the query, not a training snapshot. That distinction matters — most "AI stock pick" content is quietly using stale, memorized data.

❓ Is earnings yield a reliable way to find undervalued stocks?
✅ It's a useful, transparent starting filter, not a complete valuation model. A high earnings yield can mean genuine value or it can mean the market is pricing in a real risk (regulatory, legal, competitive) that the number doesn't capture. Always follow up with qualitative research before acting.

❓ Do I need a paid EODHD plan to run this screener?
✅ The Screener API is available on EODHD's All-In-One and All World Extended plans. Each screener request consumes 5 API calls, so a 4-stage funnel like this one costs 20 calls total — trivial even on a modest plan.

❓ What's the difference between calling the EODHD API directly and using their MCP server?
✅ Same underlying data and the same API quota either way. Direct API calls make sense once you're building a repeatable script, like the daily cron job above. The MCP server makes sense while you're still shaping the filter logic, since you can adjust it in plain language and see results immediately without touching code.

❓ How do I get alerted automatically instead of checking the screener manually?
✅ Run the funnel on a schedule (cron, Task Scheduler, or a serverless function), save each day's output, and diff it against the previous run. Route the diff to Slack, email, or a spreadsheet — the script in this article does exactly that in under 80 lines.

The market doesn't reward the investor with the best opinions.

It rewards the one with the best process for filtering out noise.

Looking for technical content for your company? I can help — LinkedIn · kevinmenesesgonzalez@gmail.com

7 Best WhatsApp APIs for Developers in 2026 (Compared)

Kevin Meneses González — Thu, 09 Jul 2026 10:02:19 +0000

Most developers reach for Twilio or Meta's official Cloud API the second WhatsApp comes up.

That's usually the wrong first move.

The official API wants Business verification, template approval, and per-message billing before you've sent a single test message. Twilio piles its own markup on top. If you're building an AI agent or a support bot that needs to talk to customers this week, you're looking at weeks of paperwork before you write a line of actual logic.

If you're:

Prototyping a WhatsApp AI agent,
shipping a chatbot fast,
or running outbound automation and want to skip Meta's approval process,

keep reading.

Why "official" isn't always the right call

The official WhatsApp Business Platform makes sense if you need the green checkmark, or you're in a regulated industry where Meta's compliance guarantees actually matter.

But getting there is slow.

Business Manager verification. App Review. Template approval that can sit for days. Per-message fees that swing wildly by country and category — marketing messages cost ten times more than utility ones in some markets.

A lot of developers don't need any of that. They just need WhatsApp wired into a backend, an LLM, or an automation pipeline, and that's where unofficial APIs come in. They connect through WhatsApp Web's protocol instead of Meta's Business Platform. You lose some compliance guarantees, you gain instant setup and flat pricing you can actually predict.

I've seen both sides of this go wrong, and not in the way people expect.

A developer picks an unofficial API to ship an MVP fast. It works, customers are happy, volume grows — and then the number gets flagged out of nowhere, because nobody warmed it up or thought about WhatsApp's spam detection. Or it goes the other direction: a team picks the official Cloud API for what's basically an internal notification bot, and burns two weeks on Business Manager and template approval for a use case that never needed that level of compliance in the first place.

Same root mistake both times. Nobody matched the API to their actual message volume and risk tolerance before committing.

TL;DR

This is a rundown of the best WhatsApp APIs for developers right now — official and unofficial, with real pricing, so you can pick the right one for an AI agent, a chatbot, or whatever automation you're building instead of guessing.

Best official WhatsApp API for AI agents: Zernio. No markup on Meta's fees, numbers from $2/month, one API call to get live.
Best flat-rate unofficial option: WAAPI at $10/mo or Whapi.Cloud at $29/mo — no per-message charges, you know your bill in advance.
Best free option if you want to self-host: CodeChat. Open source, the only ongoing cost is your own server.

1. Zernio — the official API minus the paperwork

Zernio runs on the real WhatsApp Business Platform, but somebody on their team clearly got tired of Meta's onboarding and decided to fix it.

Instead of creating a Meta app, passing App Review, and wiring up webhooks by hand, Zernio uses Meta's Embedded Signup flow. You connect a number from a dashboard in one click. No Business Manager rabbit hole.

What you actually get:

WhatsApp numbers in 53 countries, provisioned through the API, starting at $2/month. Zero markup on Meta's per-message fees — you pay what Meta charges, not the 3–5x tax Twilio adds on top. Template CRUD with automatic category tracking, so you don't get blindsided by a template silently getting reclassified into a more expensive tier. Webhooks come back in the same JSON format across WhatsApp, Instagram, and Telegram, which matters if your agent talks to more than one channel.

There's also a hosted MCP server, which means an AI agent (Claude, your own backend, whatever) can manage WhatsApp conversations through plain tool calls instead of you writing glue code for every action.

Pros

Official API, so you're not gambling on an unofficial protocol getting your number banned
Platform fee scales down at low volume, first two connected accounts are free
WhatsApp Calling API support, useful if you want to route voice to an agent

Cons

You still pay Meta's per-message fees on top, Zernio removes the markup, not the underlying cost
No visual dashboard built for non-technical teammates, this is built for developers

Best for: developers building AI agents or SaaS products who want the official API without losing a month to Meta's setup.

👉 Skip the Meta developer portal entirely — Connect a WhatsApp number and start sending messages in one API call, official Business Platform, zero markup.

2. UltraMsg — fastest unofficial setup

UltraMsg connects through WhatsApp Web's protocol. Scan a QR code, grab an instance ID and token, you're sending messages in about five minutes.

Pricing is $39/month per instance, or $390 if you pay yearly.

The upside is flexibility. Any language that can make an HTTP request can talk to it, and there's no hard message cap from UltraMsg's side (WhatsApp's own anti-spam behavior still applies, that part never goes away). The downside is the same one every unofficial API shares: your account lives or dies on WhatsApp Web session stability, not Meta's guarantees. And if you're running more than one number, the per-instance pricing adds up fast.

Good fit for a solo developer or small business that wants a working integration today and has no interest in touching Meta's portal.

3. Green API — the cheapest way to test an idea

Green API splits into two plans: Developer, which is free but capped, and Business, which runs around $8/month per instance for unlimited messaging.

What I like here is that the free tier is actually usable. It's not a three-day trial dressed up as a free plan — you can build and test a real MVP on it before paying anything. There's also a daily-billing "Partner" option if your workload is seasonal.

The tradeoffs: the free plan only handles a handful of individual chats per month, so it's testing-only, not production. And the documentation leans toward Russian-market use cases, though the English docs cover what you need.

Best for validating an idea before you commit to a paid plan anywhere.

4. WAAPI — one flat price, no surprises

WAAPI charges $10/month per instance, flat. Unlimited messages, every feature included, no tier you have to upgrade into.

That simplicity is the whole pitch. You're not parsing a pricing page trying to figure out which plan unlocks webhooks. Everything's already there.

It's a smaller company than UltraMsg or Green API, so there's less of a track record to lean on, and the same unofficial-protocol ban risk applies as everywhere else on this list. But if predictable billing matters more to you than brand history, it's hard to beat.

5. Whapi.Cloud — built for groups and channels

Whapi.Cloud does something most of the others don't bother with well: WhatsApp Groups, Channels, and Status updates. If your agent needs to post to a channel rather than just DM individual users, this is the one that actually handles it properly.

There's a free sandbox (150 messages a day, 5 active conversations a month) and then $29/month per connected number once you outgrow it.

It plugs natively into n8n, Make, and Zapier, which is nice if your team leans no-code. The sandbox is also a genuine free-forever tier, not a countdown timer. The catch is that $29/month is the second-highest flat rate on this list, and the sandbox limits make it useless past the prototype stage.

Best for anyone building Groups or Channels automation specifically, not plain one-to-one messaging.

6. CodeChat — free, open source, your server

CodeChat is for developers who'd rather run their own infrastructure than pay anyone monthly. It's built on the Baileys library, the same WebSocket engine a lot of commercial APIs use under the hood, and ships as a self-hosted REST API.

Cost: nothing, beyond whatever VPS you run it on.

The appeal is obvious if you've ever felt locked into a vendor. Full control over your data, no recurring API bill, and the codebase is battle-tested enough that it later became the foundation for Evolution API. The cost is that you're now the one responsible for uptime, scaling, and keeping the WhatsApp Web layer updated whenever WhatsApp changes something underneath you. There's no support line to call, just community docs.

If you're comfortable with Docker and don't mind owning the ops side, this is the only option on the list with zero recurring cost.

7. Wassenger — built for teams, not just developers

Wassenger is the odd one out here. It's not just an API, it's a full platform: shared team inbox, AI-drafted replies through Claude or ChatGPT, campaign tools.

Pricing runs €39.90 for Professional, €69.90 for Business, €99.90 for Enterprise, all on the official WABA.

If you need a human reviewing AI-drafted replies before they go out, the draft-and-approve workflow is genuinely useful. It also means you're not betting on an unofficial protocol. But it's the most expensive entry point on this list, and if all you need is raw API access for a backend integration, you're paying for a team inbox you'll never open.

Best for teams that want a shared inbox and AI-assisted replies bundled with their API access.

Comparison table

API	Type	Starting price	Best for
Zernio	Official	$2/month	AI agents, SaaS products
UltraMsg	Unofficial	$39/month	Fast solo setup
Green API	Unofficial	Free (capped) / $8/mo	Testing an idea
WAAPI	Unofficial	$10/month flat	Predictable billing
Whapi.Cloud	Unofficial	Free sandbox / $29/mo	Groups & Channels
CodeChat	Unofficial (self-hosted)	Free (server cost only)	Full control, zero recurring fee
Wassenger	Official	€39.90/month	Team inbox + AI replies

How to choose

Need the green checkmark, or operating somewhere regulated? Start with Zernio or Wassenger. Both run on Meta's official platform, but Zernio cuts the setup time and the per-message markup.

Just need something working today and can live with unofficial-protocol risk? WAAPI or Green API get you there for the least money.

Optimizing for zero recurring cost and full control over your stack? CodeChat is the only one here that doesn't send you a bill every month.

FAQs

What's the difference between official and unofficial WhatsApp APIs?
Official APIs like Zernio and Wassenger connect through Meta's WhatsApp Business Platform. You need Business verification and you pay per message. Unofficial APIs (UltraMsg, Green API, WAAPI, Whapi.Cloud, CodeChat) connect through WhatsApp Web's protocol instead. Setup takes minutes and pricing is usually flat per number, but there's real ban risk if you send like a spammer.

Is there a free WhatsApp API for developers?
Green API's free Developer plan is actually usable for testing, not just a teaser. CodeChat is free outright since it's open source and self-hosted — your only cost is the server it runs on.

Which WhatsApp API is best for AI agents?
Zernio is built for this specifically. It ships a hosted MCP server so an AI agent can manage WhatsApp conversations through tool calls, and it's on the official API, so you're not worried about getting banned for sending too much volume.

Can I use an unofficial WhatsApp API without getting banned?
The risk is real but manageable. Warm new numbers up slowly, only message people who opted in, don't blast a fresh number with bulk sends. If you're doing cold outbound at real scale, the official API is the safer bet.

Do these APIs charge per message?
Most unofficial ones on this list (UltraMsg, WAAPI, Whapi.Cloud) charge flat monthly fees, nothing per message. The official ones (Zernio, Wassenger) pass through Meta's per-message fees, which vary by country and message type.

If you're a software or API company looking to explain your product through high-quality educational content (not marketing fluff), feel free to connect with me on LinkedIn: linkedin.com/in/kevin-meneses-gonzalez

Looking for technical content for your company? I can help — LinkedIn · kevinmenesesgonzalez@gmail.com

How LLMs Are Replacing Legacy OCR Workflows

Kevin Meneses González — Wed, 08 Jul 2026 16:21:51 +0000

TL;DR:

OCR digitizes a page. AI document processing turns that page into structured, usable data — no templates, no rules to maintain. Unstract is an open-source, no-code platform that does this with LLMs: define what you want extracted in plain language, deploy it as an API or ETL pipeline, and get clean JSON back regardless of how the document is laid out. Start with the free 14-day trial or read the quick start guide — no credit card required.

OCR was never broken.

It just stopped being enough.

For thirty years, optical character recognition did exactly what it promised: turn pixels into characters. Feed it a scanned invoice, get back a string of text. That was the job, and it did the job well.

But reading text and understanding a document are two different problems. And the industries that depend on documents the most — finance, accounting, insurance, capital markets — have spent years discovering that the hard way.

If you're:

building automation for invoices, statements, or contracts,
maintaining an OCR pipeline that breaks every time a vendor changes their layout,
or evaluating whether to move from rule-based extraction to something smarter,

this is for you.

The 200-Bank Problem

Picture a finance team that receives bank statements from 200 different banks.

Each bank uses its own layout. Different field labels. Different date formats. Some put the account balance top-right; others bury it in a footer table. A few still send scanned PDFs that look like they were faxed twice.

Template-based OCR handles this the only way it knows how: one template per bank. 200 templates. Each one is built by hand, each one breaking the moment a bank redesigns its statement.

Now widen the lens.

An insurance underwriter doesn't just deal with bank statements — they deal with claims forms, KYC files, medical reports, and policy applications, each shaped differently depending on the insurer, the state, and the line of business. An accounting team doesn't process one invoice format — it processes one for every single vendor it works with, and vendors change their templates without asking anyone's permission.

Multiply any of these by real transaction volume, and you get a pattern every ops team eventually recognizes.

A Monday morning that repeats itself:

Someone opens 40 PDFs by hand.
Copy numbers into a spreadsheet, one cell at a time.
Pray the format didn't change since last month.
Finds three that don't match any known template and sets them aside "for later."

That's not automation. That's a workaround wearing automation's clothes.

The Real Problem Was Never Reading Text

Here's the reframe.

The problem was never extracting characters from a page. OCR solved that decades ago, and modern OCR engines hit 99%+ accuracy on printed text and roughly 95% on handwriting.

The problem is that reading text and understanding a document are not the same task.

A human accountant doesn't process an invoice by reading every character in order. They recognize this is an invoice, they know the total usually sits near the bottom, and they adjust instantly when the layout is unfamiliar. That's comprehension, not character recognition.

Legacy systems never had that layer. AI document processing exists because LLMs finally do.

That distinction is also why "just add more OCR accuracy" was never going to solve this. You can push OCR accuracy on printed characters as close to 100% as you like, and it still won't tell you which extracted number is the invoice total versus a line-item subtotal. That's a comprehension task, not a recognition task — and comprehension is what large language models bring to the table that thirty years of OCR research never could.

What Is AI Document Processing, Actually

AI document processing is the use of large language models to read, interpret, and structure the content of unstructured documents — PDFs, scans, images, spreadsheets — without relying on fixed templates or hand-coded rules.

Instead of matching a document against a predefined layout, an LLM-based pipeline reads the document the way a person would: it understands that a number preceded by "Total Due" is different from a number labeled "Subtotal," even if their position on the page changes completely from one document to the next.

Here's how the three generations actually compare:

Traditional OCR isn't obsolete — for one repetitive form, from one source, in one layout, it's still fast and cheap. But finance, insurance, and accounting teams rarely deal with one format. They deal with hundreds of variants of the same document type, arriving in whatever shape a vendor or client happens to send.

How the Pipeline Actually Works, Step by Step

Under the hood, an AI document processing pipeline is doing four distinct things, whether you notice them or not:

Parsing — turning the raw file (scanned PDF, native PDF, image, even a photo of a paper form) into text while preserving layout: tables stay tables, checkboxes stay checkboxes.
Schema definition — describing, in plain language or a JSON schema, exactly what fields matter: customer name, invoice total, claim number, whatever the business needs.
Extraction — the LLM reads the parsed document against that schema and returns structured values.
Validation — checking the extracted values for consistency, flagging low-confidence fields instead of guessing.

Most teams that try to build this themselves get step 3 working in a weekend with a raw LLM API call. Step 1 and step 4 are where things quietly fall apart in production — layout gets flattened, and a hallucinated total slips through with full confidence.

Why Building This In-House Usually Stalls

Plenty of engineering teams start this project the same way: a Python script, an LLM API call, a PDF-to-text library, done in an afternoon.

It works — on the five sample documents used to build it.

Then it hits production, and three things happen, almost every time:

A multi-column layout gets flattened into a single blob of text, and the LLM starts guessing which number belongs to which field.
The model hallucinates a value with full confidence on a document type it hasn't seen before, and nobody notices until the number is already in a report.
Token costs creep up as documents get longer, because nobody built in compression or prompt efficiency from day one.

None of these are LLM problems. They're pipeline problems — the parsing, validation, and cost layers that a raw API call skips entirely. This is precisely the gap purpose-built platforms are designed to close, instead of every team rebuilding the same missing pieces independently.

The Trend: From Templates to Prompts

Something changed in the last 24 months.

Vision-capable LLMs and layout-aware parsers made it possible to feed a document into a pipeline and get structured output back — without teaching the system what that specific document looks like first.

That shift shows up everywhere:

Schema-first extraction. You define what you want (a JSON schema), not how the document is laid out. Even foundation model providers have moved this direction — structured outputs are now a first-class feature in most major LLM APIs.
Agentic workflows. Instead of a human writing extraction rules by hand, an AI agent generates and refines the extraction logic itself, iterating against sample documents until accuracy stabilizes.
Confidence over guesswork. Modern pipelines can flag low-confidence extractions instead of silently returning wrong data — a "no value" is safer than a wrong one on a financial document.
Compliance pressure. New 2026 obligations like the EU AI Act push regulated industries — banking, insurance, life sciences — toward document workflows with audit trails and traceability, something rule-based OCR was never built to provide.

Finance and insurance are leading this shift for a simple reason: they carry the highest document volume and the highest cost of a wrong number. A misread account balance isn't a UX bug — it's a compliance problem. BFSI (banking, financial services, insurance) alone represents close to a third of the entire IDP market in 2026, and that share keeps growing as more of that volume moves to LLM-based extraction.

There's a second force behind this trend worth naming: MCP (Model Context Protocol) and the broader move toward agentic systems. AI agents making decisions — approving a claim, flagging fraud, triggering a payment — need structured, trustworthy input to act on. An agent can't reason well over a wall of unformatted OCR text. It needs the same clean JSON a downstream database would expect. That's pushing document extraction from being a back-office utility to being infrastructure other AI systems depend on directly.

This is exactly the gap Unstract was built to close.

What This Costs vs. What It Replaces

It's worth being blunt about the economics, because "AI is expensive" is the objection that kills most of these projects before they start.

LLM token costs on a single document are real, but they're not the number that matters. The number that matters is the fully-loaded cost of the alternative: a person spending 15–20 minutes per document, multiplied by hundreds of documents a week, multiplied by the error rate of manual re-keying.

Token-efficiency techniques like SinglePass and Summarized Extraction exist specifically because vendors know this comparison only holds up if per-document AI cost stays a small fraction of a person's hourly rate — which, for anything beyond a handful of documents a day, it does.

Where Unstract Fits

Unstract is an open-source, no-code platform purpose-built for extracting structured data from unstructured documents using LLMs — deployable as an API or as an ETL pipeline, without writing extraction rules by hand.

It's not a single model. It's a full pipeline, and each piece solves a specific failure mode that shows up when you try to run LLM extraction in production:

LLMWhisperer — a layout-preserving text extraction engine. It keeps tables, multi-column layouts, checkboxes, and handwritten fields intact before anything reaches the LLM, so the model isn't guessing at structure that got flattened away.
Prompt Studio — a no-code environment where you build extraction logic against real sample documents, compare output and cost across multiple LLMs side by side, and version your prompts instead of losing track of them in a spreadsheet.
LLMChallenge — Unstract's answer to hallucination. Two independent LLMs extract the same field; if they don't agree, you get NULL instead of a confidently wrong number. No value is safer than a wrong one on a financial document.
SinglePass and Summarized Extraction — techniques that cut token usage by up to 7x on large documents, which matters the moment you're processing thousands of statements a month.
API Hub and MCP Server — once a schema is built, deploy it as a callable API in one click, or connect it directly to AI agents that need reliable structured data as an input.

A few concrete benefits this unlocks:

No templates, no per-vendor maintenance. The same extraction project handles bank statements from 200 different banks, because it understands the concept of "account balance," not the position of a specific box.
Built-in hallucination control. LLMChallenge means you get validated data or nothing — never a silent wrong value slipping into a downstream system.
Open-source, no vendor lock-in. Unstract is released under AGPL 3.0. Self-host it, inspect the code, or use the managed cloud edition — your choice, your data.
Deploy without writing a pipeline from scratch. A finished extraction project becomes an API or ETL job in one click, feeding straight into Snowflake, BigQuery, or your existing database.
Document-agnostic by design. No prior training run needed per document type — you point it at samples, define the schema, and it generalizes.

👉 Try Unstract free for 14 days — no credit card required, pre-configured with an LLM, vector database, and LLMWhisperer.

You can read the full breakdown of the platform in the Unstract documentation if you want to see how the pieces connect before touching any code.

Practical Walkthrough #1: Extracting a Bank Statement

Theory is fine, but this only matters if it holds up against a real document. Let's make it concrete.

Say you receive credit card statements as PDFs — same core fields (customer name, issuer, statement date, list of transactions), wildly different formatting depending on the bank. This is one of the most common entry points teams use to test AI document processing, precisely because the pain of maintaining per-bank templates is so immediate and so familiar to anyone who has tried automating reconciliation before.

With a template-based system, this is where things get painful. With Unstract, the workflow looks like this:

Upload a handful of sample statements (from different banks) into Prompt Studio.
Define your schema in plain language — "extract customer name, statement date, total due, and list of transactions with date/description/amount."
Let Prompt Studio generate and test the extraction prompt against your samples, comparing accuracy and cost across LLMs.
Deploy as an API.

Once deployed, calling it looks like a normal REST request:

import requests

url = "https://api.unstract.com/deployment/api/<your-org>/<your-endpoint>/"
headers = {"Authorization": "Bearer YOUR_API_KEY"}
files = {"file": open("statement_chase.pdf", "rb")}

response = requests.post(url, headers=headers, files=files)
print(response.json())

The output is standard, structured JSON — regardless of which bank the statement came from:

{
  "customer_name": "John Doe",
  "issuer": "Chase",
  "statement_date": "2026-06-30",
  "total_due": 1284.55,
  "transactions": [
    {"date": "2026-06-02", "description": "Amazon.com", "amount": 42.99},
    {"date": "2026-06-05", "description": "Uber", "amount": 18.30}
  ]
}

From here you can build:

automated reconciliation pipelines that flag discrepancies
fraud detection models fed by clean transaction data
dashboards that update without anyone touching a spreadsheet

No template. No rule that breaks the next time a bank redesigns its statement.

Practical Walkthrough #2: Automating Vendor Invoice Approval

Here's a second example — a workflow that's easy to replicate if you're on an accounting or AP (accounts payable) team.

The scenario: invoices arrive by email from hundreds of vendors, every one with a different layout. Someone currently opens each one, checks it against a purchase order, and manually keys the total into the accounting system.

The schema you'd define in Prompt Studio:

{
  "vendor_name": "string",
  "invoice_number": "string",
  "invoice_date": "date",
  "due_date": "date",
  "line_items": [
    {"description": "string", "quantity": "number", "unit_price": "number", "line_total": "number"}
  ],
  "subtotal": "number",
  "tax": "number",
  "total_due": "number"
}

Once that schema is validated against a sample of invoices from different vendors, this becomes an ETL pipeline instead of a one-off API call: drop incoming invoices into a shared Google Drive or S3 folder, and Unstract automatically extracts and pushes structured rows into your accounting database.

# Pseudocode for the downstream logic once structured data lands in your DB
for invoice in new_extracted_invoices:
    po = match_purchase_order(invoice["vendor_name"], invoice["total_due"])
    if po and abs(po.amount - invoice["total_due"]) < 0.01:
        approve_for_payment(invoice)
    else:
        flag_for_manual_review(invoice, reason="PO mismatch")

The extraction layer's only job is turning a messy PDF into the JSON above. Everything downstream — matching against POs, approving payment, flagging exceptions — becomes a business logic problem instead of a "can we even read this PDF" problem.

That's the actual unlock: once documents become structured data, the rest of your stack stops needing to know it ever came from a PDF at all.

Where This Pays Off: Use Cases by Industry

1. Finance — Multi-bank statement reconciliation

The pain: A treasury or finance team pulling statements from multiple banking relationships hits the same wall every close cycle — different formats, different field labels, no shared structure. Reconciliation turns into a manual, error-prone task repeated every single month.

How AI document processing helps: One schema handles every bank's statement layout, because the extraction logic understands the concept of "closing balance" or "transaction date" rather than a fixed position on the page. The output feeds directly into reconciliation logic without a human retyping anything.

Best for: Teams closing books monthly across multiple banking relationships, or finance functions managing treasury operations across subsidiaries with different local banks.

2. Insurance — Underwriting and claims processing

The pain: Claims forms, KYC documents, and medical reports vary by insurer, state, and line of business — a nightmare for template-based systems that need a new template for every combination.

How AI document processing helps: Schema-based extraction generalizes across formats instead of requiring a template per variant. Teams running this kind of pipeline report review times dropping from days to minutes, simply because the bottleneck was never document volume — it was the seams between formats that broke automation.

Best for: Underwriting teams processing high volumes of inconsistent intake documents, and claims teams under pressure to cut turnaround time without adding headcount.

3. Accounting — Accounts payable automation

The pain: Every vendor invoices differently, and manual entry doesn't scale past a few dozen suppliers before someone becomes a full-time human OCR machine.

How AI document processing helps: Structured extraction feeds directly into PO-matching and payment approval logic, exactly as shown in Walkthrough #2 above — the invoice becomes a JSON object the moment it lands, and everything downstream is business logic, not document parsing.

Best for: AP teams handling invoices from 50+ vendors with no shared format, or finance ops teams trying to close the "three-way match" (PO, invoice, receipt) faster.

4. Capital markets — KYC and client onboarding

The pain: Onboarding documents (ID scans, proof of address, account applications) arrive in every format imaginable, and compliance requires traceable, auditable extraction — not just a fast one.

How AI document processing helps: Layout-aware parsing handles scanned and handwritten fields that break traditional OCR, while validation layers like dual-LLM consensus create the audit trail regulators increasingly expect under frameworks like the EU AI Act.

Best for: Onboarding teams under regulatory pressure to document exactly how each data point was extracted and verified, not just that it was extracted.

5. Legal and contracts — Clause and obligation extraction

The pain: Contracts share no common template, and finding specific clauses (payment terms, termination conditions, indemnification language) manually doesn't scale across a growing contract portfolio.

How AI document processing helps: Prompt-based extraction can target specific clause types across contracts of any format and length, structuring what used to require a paralegal reading every page line by line.

Best for: Legal ops teams managing large, heterogeneous contract repositories, or M&A teams running due diligence against hundreds of agreements on a deadline.

6. Healthcare-adjacent finance — Medical billing and claims reconciliation

The pain: Medical billing documents mix structured codes (CPT, ICD-10) with unstructured physician notes and inconsistent payer formats, making reconciliation between what was billed and what was paid painfully manual.

How AI document processing helps: Extraction schemas can target both the structured codes and surrounding context simultaneously, flagging discrepancies between billed and reimbursed amounts without a human cross-referencing every line.

Best for: Revenue cycle teams reconciling claims across multiple payers with inconsistent explanation-of-benefits formats.

Across every one of these use cases, the underlying pattern repeats: the documents are different, the pain is identical, and the fix is the same — stop building a template per format and start defining a schema per outcome.

Getting Started, Practically

If you want to test this against your own documents rather than take any of this on faith, the fastest path looks like this:

Pull 5–10 real samples of the document type that causes you the most pain — the messiest ones you have, not the cleanest.
Sign up for the free 14-day trial — it comes pre-configured with an LLM, vector database, embedding model, and LLMWhisperer, so there's nothing to wire up first.
Define your schema in Prompt Studio using plain language, exactly like the JSON examples in Walkthrough #1 and #2 above.
Run it against your samples and compare accuracy and cost across the available LLMs before committing to one.
Deploy as an API or ETL pipeline once the extraction is accurate enough to trust — no separate infrastructure to stand up.

The quick start guide walks through this exact sequence using a credit card statement example, if you want a guided first run before pointing it at your own documents.

Key Takeaways

OCR reads characters. AI document processing understands context — that gap is the entire reason legacy IDP struggles with document variation.
The real cost of template-based systems isn't the software. It's the ongoing human maintenance every new layout demands.
Platforms like Unstract combine layout-aware parsing, schema-based extraction, and hallucination control into one deployable pipeline — so you build the extraction logic once and let it handle the variation, whether that's bank statements, invoices, or insurance claims.

FAQs

❓ What is AI document processing?
✅ It's the use of large language models to read, interpret, and structure data from unstructured documents — PDFs, scans, images — without relying on fixed templates. Unlike OCR, which only extracts text, it extracts meaning: it understands what a field represents, not just where it sits on the page.

❓ Is OCR still useful in 2026?
✅ Yes, for narrow cases: high-volume batches of the exact same form, from the exact same source, where digitizing text is the only goal. For anything with real-world document variation, OCR alone isn't enough — that's the problem AI document processing solves.

❓ Is Unstract open source?
✅ Yes. Unstract is released under the AGPL 3.0 license, with a self-hosted open-source edition and a managed cloud edition that adds enterprise features like LLMChallenge, SSO, and human review workflows.

❓ Do I need to know how to code to use Unstract?
✅ No. Prompt Studio is a no-code environment — you define what to extract in natural language against sample documents. Developers can go further and call the resulting extraction as a REST API or embed it in an ETL pipeline.

❓ Can AI document processing handle handwritten documents?
✅ Yes. Layout-aware parsing engines like LLMWhisperer include handwritten text detection and checkbox/radio button recognition, which is where template-based OCR historically struggled the most.

❓ How is this different from just calling an LLM API directly with a PDF?
✅ A raw LLM call skips the layers that make extraction reliable in production: layout-preserving parsing so tables and forms aren't flattened, schema validation, and hallucination checks like dual-LLM consensus. Those layers are the difference between a demo and a system you can trust with financial data.

❓ How long does it take to go from zero to a working extraction pipeline?
✅ With a no-code platform, most teams get a working schema validated against sample documents within a day or two — the bulk of the time goes into gathering representative samples, not building infrastructure. Deployment as an API or ETL job happens in the same session once the schema is accurate.

❓ Can AI document processing integrate with an existing data warehouse?
✅ Yes. Platforms built for this typically support direct output to destinations like Snowflake, BigQuery, Redshift, or standard databases via ETL pipelines, so structured data lands where your analytics and reporting tools already expect it.

Legacy OCR asked documents to fit a template.

AI document processing asks the system to understand the document instead — and that's the shift finance, accounting, and insurance teams have been waiting for.

👉 Start Unstract's free trial — point it at your messiest documents first and let the comparison speak for itself.

Looking for technical content for your company? I can help — LinkedIn · kevinmenesesgonzalez@gmail.com

How to Backtest a Trading Strategy with Python and EODHD API

Kevin Meneses González — Tue, 07 Jul 2026 12:31:16 +0000

Most backtests lie to you.

Not intentionally. But they lie.

You design a strategy, run it on historical data, and watch the returns look incredible. Then you run it live — and it underperforms a simple buy-and-hold from day one. The math wasn't wrong.

The data was.

If you're:

testing momentum or mean-reversion strategies in Python,
building quant tools for personal or professional use,
or tired of backtests that collapse the moment real execution begins,

This changes how you work.

TL;DR

What this covers: Backtesting trading strategies in Python using EODHD's historical OHLCV data API
Stack: requests, pandas, numpy — no heavy frameworks (no backtrader, no vectorbt)
Scripts included:
- Script 1 — Fetch adjusted historical price data from EODHD
- Script 2 — SMA crossover strategy (20/50-day)
- Script 3 — RSI mean-reversion strategy
- Script 4 — Performance metrics: Sharpe ratio, max drawdown, win rate
EODHD pricing: Free tier available; full access from $19.99/month
Best for: Developers and analysts who need reliable, split/dividend-adjusted data without scraping

The Problem with Free Data

Most developers start with Yahoo Finance or a scraped CSV.

That works fine for a quick prototype. It stops working the moment your strategy includes anything that happened around a stock split, dividend payment, or ticker change.

Non-adjusted price data creates ghost signals. A stock "drops 50%" when it actually split 2:1. Your moving average calculates a crossover that never happened in real life. Your strategy looks profitable because it's trading on a data artifact.

The free path costs you accuracy. And in backtesting, accuracy is the whole point.

The Fix Is Simpler Than You Think

The real bottleneck isn't the strategy logic. It's the data source.

Use split- and dividend-adjusted closing prices from a reliable provider, and half your backtest reliability problems disappear before you write a single signal.

EODHD APIs provides exactly this. Their historical data endpoint returns adjusted OHLCV data for 70,000+ tickers across 50+ exchanges, via a simple REST API. No scraping. No undocumented endpoints that break on weekends.

EODHD Financial Data API
Adjusted historical prices, fundamentals, and real-time data for 70,000+ tickers.
→ Start free at eodhd.com

Setup

Install the required libraries:

pip install requests pandas numpy

Set your API token:

API_TOKEN = "your_eodhd_api_token_here"

You can get a free token at eodhd.com. The free tier includes end-of-day data for US tickers with a 1-year delay — enough to test strategies.

Script 1: Fetch Historical OHLCV Data from EODHD

The foundation of every backtest is the raw price series. This function pulls adjusted daily OHLCV data for any ticker and returns a clean pandas DataFrame.

import requests
import pandas as pd

API_TOKEN = "your_eodhd_api_token_here"

def get_historical_data(symbol: str, exchange: str = "US",
                        start: str = "2020-01-01", end: str = "2024-12-31") -> pd.DataFrame:
    """
    Fetch adjusted EOD OHLCV data from EODHD for a given symbol.
    Returns a DataFrame indexed by date.
    """
    url = f"https://eodhd.com/api/eod/{symbol}.{exchange}"
    params = {
        "api_token": API_TOKEN,
        "fmt": "json",
        "from": start,
        "to": end
    }
    response = requests.get(url, params=params)
    response.raise_for_status()

    df = pd.DataFrame(response.json())
    df["date"] = pd.to_datetime(df["date"])
    df.set_index("date", inplace=True)

    return df[["open", "high", "low", "close", "adjusted_close", "volume"]]


# Example usage
df = get_historical_data("AAPL", start="2020-01-01", end="2024-12-31")
print(df.tail())

Sample output:

            open    high     low   close  adjusted_close      volume
date
2024-12-24  255.5  258.4  254.2  257.9          257.9   32145600
2024-12-26  258.1  261.0  257.3  259.3          259.3   28761300
2024-12-27  258.8  259.4  254.6  255.6          255.6   41232100
2024-12-30  253.1  254.3  250.7  251.8          251.8   39814700
2024-12-31  250.4  252.1  248.9  250.4          250.4   44021900

Note the adjusted_close column. That's what you backtest on — not raw close.

Script 2: SMA Crossover Strategy

The 20/50-day SMA crossover is the classic momentum signal: go long when the short-term average crosses above the long-term, exit when it crosses below.

Simple in theory. The implementation details matter.

def sma_crossover_backtest(df: pd.DataFrame,
                           short_window: int = 20,
                           long_window: int = 50) -> pd.DataFrame:
    """
    SMA crossover strategy using adjusted closing prices.
    Signal:  1 = long, -1 = short, 0 = flat
    Position is shifted by 1 day to prevent look-ahead bias.
    """
    df = df.copy()

    df["sma_short"] = df["adjusted_close"].rolling(short_window).mean()
    df["sma_long"]  = df["adjusted_close"].rolling(long_window).mean()

    # Raw signal
    df["signal"] = 0
    df.loc[df["sma_short"] > df["sma_long"], "signal"] =  1
    df.loc[df["sma_short"] < df["sma_long"], "signal"] = -1

    # Shift by 1 to trade on the *next* day's open — no look-ahead
    df["position"] = df["signal"].shift(1)

    # Returns
    df["market_return"]   = df["adjusted_close"].pct_change()
    df["strategy_return"] = df["position"] * df["market_return"]

    # Cumulative performance
    df["cumulative_market"]   = (1 + df["market_return"]).cumprod()
    df["cumulative_strategy"] = (1 + df["strategy_return"]).cumprod()

    return df


# Run it
df = get_historical_data("AAPL", start="2020-01-01", end="2024-12-31")
result_sma = sma_crossover_backtest(df)

final_market   = result_sma["cumulative_market"].iloc[-1]
final_strategy = result_sma["cumulative_strategy"].iloc[-1]

print(f"Buy & Hold return:   {(final_market - 1):.2%}")
print(f"SMA Strategy return: {(final_strategy - 1):.2%}")

The shift(1) on line 16 is the single most important detail. Without it, you're using today's signal to trade today's close — which is impossible in real life and produces inflated results.

Script 3: RSI Mean-Reversion Strategy

RSI (Relative Strength Index) measures the speed of price changes on a 0–100 scale. Values below 30 signal oversold conditions; above 70 signals overbought.

The mean-reversion hypothesis: when a stock is oversold, it tends to recover. When overbought, it tends to pull back.

import numpy as np

def calculate_rsi(series: pd.Series, period: int = 14) -> pd.Series:
    """Wilder's RSI using simple moving averages of gains and losses."""
    delta = series.diff()
    gain  = delta.clip(lower=0)
    loss  = -delta.clip(upper=0)

    avg_gain = gain.rolling(period).mean()
    avg_loss = loss.rolling(period).mean()

    rs = avg_gain / avg_loss
    return 100 - (100 / (1 + rs))


def rsi_strategy_backtest(df: pd.DataFrame,
                          rsi_period: int = 14,
                          oversold: int = 30,
                          overbought: int = 70) -> pd.DataFrame:
    """
    RSI mean-reversion strategy.
    Enter long when RSI drops below 'oversold'.
    Exit (go flat) when RSI rises above 'overbought'.
    """
    df = df.copy()
    df["rsi"] = calculate_rsi(df["adjusted_close"], rsi_period)

    df["signal"] = 0
    df.loc[df["rsi"] < oversold,   "signal"] =  1   # Buy oversold
    df.loc[df["rsi"] > overbought, "signal"] = -1   # Sell overbought

    # Hold position between signals (forward-fill non-zero values)
    df["position"] = (
        df["signal"]
        .replace(0, np.nan)
        .ffill()
        .fillna(0)
        .shift(1)   # Again: no look-ahead
    )

    df["market_return"]   = df["adjusted_close"].pct_change()
    df["strategy_return"] = df["position"] * df["market_return"]

    df["cumulative_market"]   = (1 + df["market_return"]).cumprod()
    df["cumulative_strategy"] = (1 + df["strategy_return"]).cumprod()

    return df


# Run it
result_rsi = rsi_strategy_backtest(df)

print(f"Buy & Hold return:   {(result_rsi['cumulative_market'].iloc[-1] - 1):.2%}")
print(f"RSI Strategy return: {(result_rsi['cumulative_strategy'].iloc[-1] - 1):.2%}")

Script 4: Performance Metrics (Sharpe, Max Drawdown, Win Rate)

Return alone means nothing. A strategy returning 40% with -60% max drawdown is not a good strategy.

This function calculates the three metrics that matter most for evaluating any backtest:

def calculate_performance(df: pd.DataFrame,
                          risk_free_rate: float = 0.04) -> dict:
    """
    Compute annualized return, Sharpe ratio, max drawdown, and win rate
    for a backtested strategy DataFrame.
    """
    strategy_returns = df["strategy_return"].dropna()

    # Annualized return
    total_days = len(strategy_returns)
    annual_factor = 252 / total_days
    strategy_ann = (df["cumulative_strategy"].iloc[-1] ** annual_factor) - 1
    market_ann   = (df["cumulative_market"].iloc[-1] ** annual_factor) - 1

    # Sharpe ratio (annualized)
    daily_rf = risk_free_rate / 252
    excess   = strategy_returns - daily_rf
    sharpe   = np.sqrt(252) * excess.mean() / excess.std()

    # Maximum drawdown
    cumulative  = df["cumulative_strategy"].dropna()
    rolling_max = cumulative.cummax()
    drawdown    = (cumulative - rolling_max) / rolling_max
    max_dd      = drawdown.min()

    # Win rate (percentage of profitable trading days)
    active   = strategy_returns[strategy_returns != 0]
    win_rate = (active > 0).sum() / len(active)

    return {
        "Strategy Annualized Return": f"{strategy_ann:.2%}",
        "Market Annualized Return":   f"{market_ann:.2%}",
        "Sharpe Ratio":               f"{sharpe:.2f}",
        "Max Drawdown":               f"{max_dd:.2%}",
        "Win Rate":                   f"{win_rate:.2%}",
    }


# Evaluate both strategies
print("=== SMA Crossover ===")
for k, v in calculate_performance(result_sma).items():
    print(f"  {k}: {v}")

print("\n=== RSI Mean-Reversion ===")
for k, v in calculate_performance(result_rsi).items():
    print(f"  {k}: {v}")

Sample output (AAPL, 2020–2024):

=== SMA Crossover ===
  Strategy Annualized Return: 18.4%
  Market Annualized Return:   22.1%
  Sharpe Ratio:               0.91
  Max Drawdown:              -14.3%
  Win Rate:                   53.2%

=== RSI Mean-Reversion ===
  Strategy Annualized Return: 15.7%
  Market Annualized Return:   22.1%
  Sharpe Ratio:               0.78
  Max Drawdown:              -18.6%
  Win Rate:                   51.8%

In this case, buy-and-hold wins on raw return. But look at the max drawdown: the SMA strategy cuts the worst-case scenario from -30%+ to -14%. That's the real value — risk-adjusted performance, not just raw returns.

Putting It All Together

Here's the full pipeline: fetch data, run both strategies, compare metrics.

# Full backtest pipeline
symbols = ["AAPL", "MSFT", "NVDA"]

for ticker in symbols:
    print(f"\n{'='*40}")
    print(f"  {ticker}")
    print(f"{'='*40}")

    data = get_historical_data(ticker, start="2021-01-01", end="2024-12-31")

    sma_result = sma_crossover_backtest(data)
    rsi_result = rsi_strategy_backtest(data)

    print("  SMA Crossover:")
    for k, v in calculate_performance(sma_result).items():
        print(f"    {k}: {v}")

    print("  RSI Mean-Reversion:")
    for k, v in calculate_performance(rsi_result).items():
        print(f"    {k}: {v}")

From here you can build:

a parameter optimization loop (walk-forward testing)
a multi-ticker portfolio backtest with position sizing
a live signal generator using EODHD's real-time endpoints
a dashboard to visualize equity curves and drawdown periods

FAQs

❓ Is EODHD data adjusted for stock splits and dividends?
✅ Yes. The adjusted_close field in the API response accounts for both splits and dividends. Always use this field for backtesting — raw close prices will produce misleading signals around corporate actions.

❓ Can I backtest strategies on non-US markets with EODHD?
✅ EODHD covers 50+ exchanges including LSE, TSX, ASX, Euronext, and major Asian markets. Just change the exchange parameter in the API call (e.g., "LSE" for London, "TO" for Toronto).

❓ Does this approach suffer from survivorship bias?
✅ Potentially yes, if you only test on stocks that still exist today. To minimize it, include delisted tickers in your universe. EODHD provides data for delisted stocks — you can query them using their historical ticker symbols.

❓ What's the difference between a good Sharpe ratio and a bad one?
✅ As a general benchmark: below 0.5 is weak, 0.5–1.0 is acceptable, above 1.0 is considered good. Above 2.0 in a backtest should raise suspicion — it often signals overfitting to historical noise.

❓ Is there a free tier on EODHD to try this?
✅ Yes. EODHD offers a free API key that includes EOD data for US tickers. You can run all the scripts in this article with the free tier. Paid plans start at $19.99/month and unlock real-time data, fundamentals, and full global coverage.

Before You Ship Your Strategy Live

Two things to check before treating any backtest as real:

Transaction costs. Every trade has a spread and a commission. Add a -0.001 cost per trade (0.1%) to your strategy_return calculation and see if the edge survives.

Overfitting. If you tuned your parameters (RSI period, SMA windows) on the same data you're testing on, your results are optimistic. Use a walk-forward split: train on 70% of the data, test on the remaining 30%.

Bad data tells you the strategy works. Good data tells you the truth.

EODHD Financial Data API
Adjusted historical prices for 70,000+ tickers across 50+ global exchanges. REST API, JSON responses, Python-friendly.
→ Start free — no credit card required

Looking for technical content for your company? I can help — LinkedIn · kevinmenesesgonzalez@gmail.com

The 5 Best Insider Trading APIs for Developers in 2026 (Compared)

Kevin Meneses González — Mon, 06 Jul 2026 14:52:54 +0000

TL;DR

Insider trading data comes from SEC Form 4 filings. The API you pick determines whether you get a raw buy/sell flag or a real signal (scheduled 10b5-1 sale vs. open-market conviction move).
EODHD ($59.99/mo) — best value, bundled with fundamentals, new Form 4 schema shipped May 2026.
sec-api.io ($49–239/mo) — most comprehensive SEC form-type coverage, dedicated product.
Financial Modeling Prep ($19–99/mo) — cheapest entry point, good if you already need fundamentals.
Quiver Quantitative ($75/mo) — alternative-data angle, dashboards included, no commercial rights.
edgartools (free, open-source) — build it yourself, zero cost, zero SLA.
Full comparison, pricing table, Python example, and FAQ below.

Every insider-trading tutorial online uses the same three tickers: Tesla, Apple, Nvidia.

That's not laziness. It's because insider data is genuinely useful for exactly one thing: telling you whether the people who run a company are buying or selling their own stock, before the market notices.

The problem isn't finding an API that has this data.

Every financial data provider claims to have it.

The problem is that most of them give you a flattened buy/sell flag with no context, no derivative transactions, and no way to tell a scheduled sale from a real signal.

The reframe: the schema matters more than the coverage

A CFO selling 50,000 shares looks alarming — until you learn it was scheduled 90 days ago under a Rule 10b5-1 plan, filed as an affirmative defense against insider-trading liability.

Without that footnote, every API looks the same: a name, a ticker, a P or an S.

With it, you can separate noise from signal.

That single field — 10b5-1 plan detection — is the line that splits this list into "usable for research" and "usable for screenshots."

The 5 compared

1. EODHD — best value, bundled with fundamentals

EODHD rebuilt its Insider Transactions API in May 2026, moving from a flattened one-year feed to a full Form 4 schema pulled directly from SEC EDGAR.

Pros

Full SEC transaction code set (15 codes), not just P/S
Non-derivative and derivative transactions plus resolved footnotes (10b5-1 detection) in the same object
5–11 years of history for large caps (AAPL, MSFT, NVDA, KO, GME confirmed)
Bundled with fundamentals, calendar, and ratios in the same plan — one API key for both

Cons

US-listed issuers only (same limitation as every provider on this list — Form 4 is a US SEC requirement)
History depth for smaller/newer tickers still being backfilled as of mid-2026

Best for: developers who already need (or will need) fundamentals data and want insider transactions bundled instead of paying for a second vendor.

2. sec-api.io — most comprehensive SEC coverage

A commercial API layer over the entire SEC EDGAR archive, not just Form 4.

Pros

Broadest form-type coverage of any provider here: Forms 3/4/5, 13F, 13D/G, S-1, Form 144, N-PORT, and 800+ others
Real-time WebSocket streaming of new filings, indexed in under 300ms of publication
Native aff10b5One boolean field for 10b5-1 detection (post-2023 filings) — cleaner than footnote text-matching

Cons

Free tier is 100 lifetime calls, not monthly — burns fast during development
Jumps from $49–55/mo (Personal) to $199–239/mo (Business) with no middle tier

Best for: teams that need insider data as one piece of a much larger SEC-filings pipeline (10-K/10-Q parsing, real-time filing alerts, XBRL extraction).

3. Financial Modeling Prep — cheapest bundled entry

FMP folds insider transactions into its broader fundamentals-and-filings package.

Pros

Starter tier at $19/mo is the lowest paid entry point on this list
Same API key covers financial statements, ratios, DCF valuations, and earnings transcripts
Well-documented, with Google Sheets/Excel add-ons for non-coders on the team

Cons

Insider-specific documentation and schema depth (footnote resolution, transaction code breadth) is thinner than EODHD or sec-api.io
Real-time/intraday features are gated behind higher tiers ($49+/mo)

Best for: early-stage projects that want one cheap API covering fundamentals + insider data without much filtering sophistication.

4. Quiver Quantitative — the alternative-data angle

Quiver treats insider trading as one dataset among 30+ alternative signals (Congress trading, lobbying, patents, app ratings).

Pros

Ships with pre-built dashboards, not just raw JSON — useful if you want a UI fast
Insider data sits next to Congressional trading, so cross-referencing "who's buying what" across insiders and politicians is one query away
MCP server available for natural-language queries from Claude or Cursor

Cons

Insider Trading is gated behind the $75/mo Trader tier ($62.50/mo billed annually) — the $30/mo Hobbyist tier doesn't include it
Explicitly no commercial-use rights below the enterprise tier

Best for: individual researchers who want insider data alongside other alt-data signals in one dashboard, not developers building a production pipeline.

5. edgartools — free, open-source, DIY

Not a hosted API. A Python library (5M+ PyPI downloads) that parses SEC EDGAR directly.

Pros

Completely free, no API key, no rate-limit anxiety
Parses Form 4 into structured objects with computed helpers like get_ownership_summary() and get_net_shares_traded()
Handles amendments (3/A, 4/A, 5/A) transparently

Cons

You maintain the infrastructure — no SLA, no support line, no guaranteed uptime
No bundled fundamentals, no hosted dashboard, no MCP server

Best for: solo developers or students prototyping an idea before committing budget to a paid provider.

Quick comparison

Provider	Entry price	Insider-specific schema depth	Bundled fundamentals
EODHD	$59.99/mo	High (15 codes, footnotes, derivatives)	Yes
sec-api.io	$49/mo	Highest (native 10b5-1 flag)	No (filings-focused)
FMP	$19/mo	Medium	Yes
Quiver Quantitative	$75/mo	Medium (alt-data framing)	No
edgartools	Free	High (open-source parsing)	No

Building a conviction-signal screener (EODHD example)

Since EODHD is the best-value pick for anyone who also needs fundamentals, here's the fastest path from API key to a working screener.

pip install requests

import requests

API_TOKEN = "YOUR_TOKEN"
SYMBOL = "NVDA"

url = f"https://eodhd.com/api/sec-filings/{SYMBOL}/form4"
params = {"api_token": API_TOKEN, "page[limit]": 50}

response = requests.get(url, params=params)
filings = response.json()["data"]

for filing in filings:
    footnote_text = " ".join(f["text"] for f in filing["footnotes"])
    is_10b5_1 = "10b5-1" in footnote_text

    for tx in filing["non_derivative"]:
        if tx["transaction_code"] != "S":
            continue

        signal = "scheduled (10b5-1)" if is_10b5_1 else "open-market"
        print(
            f"{tx['reporting_owner_name']} ({tx.get('officer_title') or 'insider'}) "
            f"sold {tx['shares_amount']} shares at ${tx['price_per_share']} "
            f"— {signal}"
        )

Output:

Jensen Huang (Chief Executive Officer) sold 25000 shares at $890 — scheduled (10b5-1)
Colette Kress (Chief Financial Officer) sold 12000 shares at $885 — scheduled (10b5-1)

From here you can build:

an alert bot that only fires on non-scheduled (open-market) sales — the ones that actually carry signal
a dashboard cross-referencing insider activity with earnings dates and price action
a screener ranking your entire watchlist by dollar value of non-scheduled transactions

👉 Get a free API key here: EODHD

Pricing model summary

Plan type	Price	What it unlocks
EODHD Free	$0/mo	20 calls/day, no Fundamentals access
EODHD Fundamentals	$59.99/mo	Financials, ratios, calendar, Form 4 insider transactions
EODHD All-in-One	$99.99/mo	Everything above + real-time, news, options
sec-api.io Personal	$49–55/mo	Insider Trading API + core SEC endpoints
sec-api.io Business	$199–239/mo	Higher volume, redistribution rights
FMP Starter	$19/mo	300 calls/min, 5-year history, insider data included
Quiver Trader	$62.50–75/mo	Insider Trading + 30 alt-data sets, no commercial rights
edgartools	$0	Self-hosted, unlimited, zero support

Each EODHD Form 4 request consumes 10 API calls against your daily quota; pagination is capped at 100 filings per page.

Known limitations across all providers

US-only. Form 4 is a US SEC requirement. None of these APIs cover non-US insider disclosures.
Blackout gaps are expected. No filings in the 4–6 weeks before earnings usually means insiders are in a blackout period, not that nothing happened.
History depth varies by ticker, not just by provider — large caps go back years, small/recent listings may only have 12 months regardless of which API you use.

FAQ

What's the difference between Form 3, 4, and 5?
Form 3 is the initial ownership statement when someone becomes an insider. Form 4 reports changes (buys, sells, grants) within two business days. Form 5 is an annual catch-up for anything not reported on Form 4. Almost all insider-trading analysis uses Form 4.

How do I detect scheduled (10b5-1) sales vs. real signal?
Since the SEC's 2023 amendments, newer Form 4 filings include an explicit affirmation field; for older filings, search the footnote text for "10b5-1". EODHD and sec-api.io both expose this — EODHD via resolved footnotes, sec-api.io via a native boolean.

Can any of these APIs cover non-US insider trading?
No. Form 4 is exclusively a US SEC requirement. For other markets you'd need each country's local equivalent (rare to find via API).

Is there a free option that isn't a trial?
Yes — edgartools is free and open-source with no usage cap, but you host and maintain it yourself.

Which one should I pick if I already use EODHD or FMP for prices/fundamentals?
Stay on the same provider. Both bundle insider transactions into their existing fundamentals plans, so adding insider data costs nothing extra in vendor overhead.

Key takeaways

The 10b5-1 flag is the single most useful field in insider-trading data — it's what turns a raw sell transaction into an actual signal.
If you already need fundamentals data, EODHD or FMP make more sense than a dedicated insider-only vendor.
If insider data is one piece of a bigger SEC-filings pipeline, sec-api.io's broader form coverage justifies the higher price.
If budget is zero and you're comfortable maintaining your own code, edgartools gets you the same underlying data for free.

Looking for technical content for your company? I can help — LinkedIn · kevinmenesesgonzalez@gmail.com

I Let Claude Analyze 500 Stocks—Here's What It Picked

Kevin Meneses González — Sun, 21 Jun 2026 14:43:02 +0000

"AI picked these stocks" is one of the most repeated claims on FinTwit right now.

Almost none of it is reproducible.

Screenshot of a ChatGPT chat. No data source. No filters. No way to check if the tickers even exist. If you're:

building AI agents that touch market data,
evaluating whether LLMs can actually reason over financial datasets,
or just tired of "AI stock picker" threads with zero code attached,

this one's different. Every number below came from a live screen. There's code for developers and a copy-paste prompt for everyone else.

Why "Ask ChatGPT to Pick Stocks" Doesn't Work

Most "AI stock picking" content fails for one boring reason: the model never touches real data.

You ask an LLM to "analyze the market," and it answers from training data that's months or years stale. It might invent a ticker. It might quote a P/E ratio from memory that hasn't been true since 2023.

Developers discover this too late — usually after publishing a "top 10 AI stock picks" post and getting called out in the comments for a ticker that delisted last year.

The reasoning isn't the problem.

The data pipeline is.

The Real Problem Isn't Intelligence. It's Blindness.

Claude can reason extremely well over structured data — rank by valuation, weigh momentum against volatility, spot a sector cluster.

What it can't do on its own is see the market.

Give it that, and the "AI stock picker" stops being a parlor trick and starts being an actual screening assistant.

Giving Claude Eyes: EODHD's MCP Server

EODHD exposes a stock screener as an MCP tool. Instead of scraping pages or hardcoding a REST client, Claude connects directly to it and calls it like any other tool.

Through the MCP connection, Claude gets:

Live fundamentals (market cap, P/E, EPS, dividend yield)
Price performance windows (1-day and 5-day returns)
Volume data to filter out illiquid noise
Sector and industry tags for clustering

No scraping. No stale CSV exports. No hallucinated tickers — every result is a real, currently-listed instrument.

If you're already using EODHD for other projects, this is the same dataset — just exposed as a tool Claude can call directly instead of a REST endpoint you wrap yourself.

👉 Explore the EODHD MCP integration

Try It Yourself — No Code Required

You don't need an API key or a Python environment to test this. If you have Claude with the EODHD connector enabled, paste this prompt directly into the chat:

Connect to the EODHD MCP stock screener and run this exact query:

- US-listed stocks only
- Market capitalization above $10 billion
- Average 200-day volume above 1 million shares
- Sort by 5-day return, descending
- Return the top 10 results

For each result, show: ticker, company name, sector, 5-day return %,
and market cap. Then add one sentence identifying any sector pattern
across the list — don't force a narrative if there isn't one.

That's it. Claude calls the tool, gets back real rows, and reasons over them the same way it would for the code version below.

A few ways to push it further once you've run the base prompt:

Now filter that same list down to only the Technology sector
and explain what's driving the move in plain English.

Re-run the screen but swap 5-day return for market cap above $50B
and dividend yield above 2%. I want value, not momentum.

Setting Up the Connection (For Developers)

The MCP config is what makes this work for anyone building it into an app instead of chatting it manually.

MCP server config (Claude Desktop or API):

{
  "mcpServers": {
    "eodhd": {
      "url": "https://mcpv2.eodhd.dev/v2/mcp",
      "type": "url"
    }
  }
}

Calling it via the API:

import anthropic

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=2000,
    mcp_servers=[
        {
            "type": "url",
            "url": "https://mcpv2.eodhd.dev/v2/mcp",
            "name": "eodhd-mcp"
        }
    ],
    messages=[{
        "role": "user",
        "content": (
            "Screen US stocks with market cap above $10B and average "
            "200-day volume above 1M shares. Sort by 5-day return descending. "
            "Return the top 10 with sector and a one-line reason for momentum."
        )
    }],
    extra_headers={"anthropic-beta": "mcp-client-2025-04-04"}
)

print(response.content)

Behind the scenes, Claude translates the plain-language request into a structured call to the screener tool — filtering by market_capitalization, avgvol_200d, and sorting by refund_5d_p — and gets back real rows, not a guess.

From here you can build:

a daily momentum digest delivered to Slack
a screener bot wired into a Telegram channel
a backtesting loop that screens, logs picks, and checks them a week later

What Came Back: 10 Real Picks From a Live Screen

Filters: US-listed, market cap above $10B, average 200-day volume above 1M shares, sorted by 5-day return.

This wasn't curated. It's the raw output, ranked by Claude after the screener returned the candidates.

Ticker	Company	Sector	5d Return	Mkt Cap
WDC	Western Digital	Technology	+40.99%	$257B
BE	Bloom Energy	Industrials	+32.16%	$93.6B
NBIS	Nebius Group	Communication Services	+29.00%	$72.8B
CIFR	Cipher Mining	Technology	+28.94%	$11.9B
MRNA	Moderna	Healthcare	+28.85%	$25.4B
ARM	Arm Holdings	Technology	+28.41%	$469B
ENTG	Entegris	Technology	+23.36%	$27.2B
STX	Seagate Technology	Technology	+23.29%	$242B
CRWV	CoreWeave	Technology	+23.20%	$64.4B
ALGM	Allegro Microsystems	Technology	+23.02%	$11B

Claude's read on the cluster: seven of the ten sit in storage, semiconductors, or AI infrastructure — Western Digital and Seagate riding a hard-drive demand spike, Arm and Entegris tied to the chip cycle, CoreWeave and Nebius both pure AI-compute plays.

That's not Claude being clever. That's the screen surfacing a real sector rotation, and Claude naming the pattern instead of leaving you to spot it in a spreadsheet.

Moderna is the outlier — a biotech name riding its own news cycle, disconnected from the hardware story.

A Practical Guide to Screening With Claude + MCP

Running one screen is easy. Getting useful output every time takes a bit more discipline.

1. Always specify liquidity, not just size.
Market cap alone lets illiquid OTC tickers sneak in — names that move 200% on 200 shares traded. Add a volume filter (avgvol_200d > 1,000,000) or you'll get noise dressed up as momentum.

2. Separate the screen from the narrative.
Ask Claude to return raw data first. Then, in a second message, ask it to interpret the pattern. Mixing both in one prompt makes it more likely Claude reaches for a story before checking if one's actually there.

3. Re-run before you publish.
Market data is a snapshot. A screen run on Monday is stale by Friday. If you're writing this up for a newsletter or post, re-run it the morning you publish.

4. Pin your filters in the prompt, not in your head.
"Large, liquid, momentum stocks" means nothing to a screener. "Market cap > $10B, avgvol_200d > 1M, sorted by refund_5d_p descending" means everything. Specificity is the whole game.

5. Use sector clustering as a sanity check, not a conclusion.
If 7 of 10 picks share a sector, that's a real signal worth investigating — not proof you've found alpha. Treat it as a research starting point.

6. Cross-check anything you'd act on.
A screener tells you what moved. It doesn't tell you why a specific company moved, or whether the move is sustainable. Pull the news, check the earnings calendar, read the filing — before any of this touches real money.

Key Takeaways

A reproducible screen beats a screenshot every time — anyone can run this exact query and check the output
MCP turns Claude from a chatbot into an agent with real market eyes, no custom REST wrapper required
This is a starting filter for further research, not investment advice — verify before you act on any of it

FAQs

❓ Can I run this without writing any code?
✅ Yes. If you have the EODHD MCP connector enabled in Claude, just paste the prompt in the "Try It Yourself" section above. Claude calls the screener tool directly — no API key setup or Python environment needed.

❓ Is the EODHD MCP server free to use?
✅ It depends on your EODHD API plan — the screener tool consumes API calls against your existing subscription tier. Check EODHD's pricing page for current limits on screener calls per day.

❓ Does Claude ever hallucinate tickers when using MCP?
✅ No, not when the data comes through the tool call. Every ticker in the results above came directly from the screener response — Claude is reasoning over real rows, not generating them from memory.

❓ Can I use this for sectors other than tech?
✅ Yes. Swap the filters in the prompt — set sector = "Healthcare" or sector = "Energy" and re-run. The screener supports filtering by sector, industry, country, and several other fields.

❓ Is this financial advice?
✅ No. This is a demonstration of a reproducible screening workflow. The output is a filtered list based on price momentum and market cap, not a recommendation to buy or sell anything.

❓ What's the difference between this and just asking ChatGPT to pick stocks?
✅ Without a connected data tool, an LLM answers from training data that can be stale by months. With MCP, Claude is calling a live screener and reasoning over real, current numbers — the difference between guessing and looking.

If you're a software or API company looking to explain your product through high-quality educational content (not marketing fluff), feel free to connect with me on LinkedIn.

👉 Get started with EODHD's API and MCP server

Looking for technical content for your company? I can help — LinkedIn · kevinmenesesgonzalez@gmail.com

Building a Finviz Alternative With Claude Code and EODHD API

Kevin Meneses González — Sat, 20 Jun 2026 13:56:19 +0000

Most investors think they need more tools to make better decisions.

The truth is different.

If you're:

screening stocks across multiple sources,
checking sector performance on a separate site,
or tracking ideas in a spreadsheet that's always out of date,

you don't have a tools problem. You have a fragmentation problem.

A typical investing workflow looks like this:

Finviz for screening stocks
Yahoo Finance for company information
TradingView for charts
Another site for market breadth
Excel for tracking ideas

Too many tabs.
Too much context switching.

The more fragmented the workflow, the harder it is to spot opportunities.

So instead of opening five different tools every morning, I built one: FinView, an open-source Finviz alternative powered by Claude Code and the EODHD API.

The Real Problem Isn't Data — It's Structure

Developers building their own stock market dashboard usually hit the same wall.

Data is scattered across providers. Real-time prices come from one source, fundamentals from another, historical data from a third. Stitching that together used to take weeks.

The real problem isn't a lack of financial data.

It's the lack of a single, reliable source feeding a clean structure.

That's the gap FinView was built to close: one dashboard, one API, every workflow a Finviz user expects.

What FinView Includes

The goal was simple: answer five questions without leaving one screen.

What is the market doing today?
Which sectors are leading?
What stocks have unusual volume?
What companies deserve deeper analysis?
Is the market bullish or bearish?

1. Real-Time Market Dashboard

The homepage gives an instant read on market conditions:

S&P 500, Nasdaq, Dow Jones, Russell 2000
Market breadth indicators
Advance/decline ratios
Bull vs. bear sentiment

Before looking for opportunities, you need to understand the environment. This section does that in seconds.

2. Stock Screener

Finviz's screener is its most-used feature, so FinView needed the same logic.

Users can filter stocks by:

Price
Volume
Relative performance
Technical signals

Instead of manually scanning charts, the screener surfaces stocks hitting new highs, showing unusual volume, or leading the day's gainers and losers — instantly.

3. Sector Heatmap

This is the feature that does the most work with the least effort.

A heatmap makes rotation visible at a glance: technology weak, utilities strong, financials leading, industrials outperforming. One visualization often reveals more than three market reports combined.

4. Company Detail Pages

Finding a stock is only step one. Understanding it is where decisions actually happen.

Each company page shows market data, fundamental metrics, historical performance, and key company information — creating a clean path from discovery to analysis.

How Claude Code Changed the Build

The interesting part wasn't the dashboard. It was the process.

Five years ago, a project like this meant:

Frontend development
Backend architecture
Database design
API integrations
UI design and testing

Weeks, sometimes months, of work.

With Claude Code, most of that repetitive implementation got handled automatically. I focused on product design, architecture decisions, and data integration instead.

This doesn't replace software engineering.

It removes the boilerplate so the engineering that matters gets more attention.

Connecting the EODHD API

A dashboard is only as good as its data feed. FinView needed one provider that covered real-time prices, historical data, fundamentals, and global market coverage — without juggling three separate integrations.

This is where the EODHD API fits in. It provides:

Real-time market data
Historical price data
Company fundamentals
Market indices and sector data
Global exchange coverage

A simplified example of pulling stock data:

import requests

API_KEY = "YOUR_API_KEY"
symbol = "AAPL"

url = f"https://eodhd.com/api/real-time/{symbol}?api_token={API_KEY}&fmt=json"
data = requests.get(url).json()

print(data)

From here you can build:

screeners
alert systems
AI trading agents

Looking for one API instead of five?
EODHD gives you real-time prices, fundamentals, and historical data in a single REST API — no scraping, no rate-limit roulette.
→ Explore EODHD APIs

Building the Market Overview

indices = ["^GSPC", "^IXIC", "^DJI", "^RUT"]

for symbol in indices:
    data = get_market_data(symbol)
    print(symbol, data["close"])

This powers the market snapshot at the top of the dashboard.

Building the Screener

filtered = []

for stock in stocks:
    if stock["volume"] > 1_000_000 and stock["change_percent"] > 5:
        filtered.append(stock)

print(filtered)

The production version supports far more filters, but the logic stays the same: retrieve data, apply conditions, display opportunities.

Why This Project Is Open Source

Developers learn faster from real projects than from documentation alone.

The FinView repository demonstrates:

Claude Code development workflows
EODHD API integration patterns
Dashboard and screener architecture
Sector heatmap logic

If you're learning AI-assisted development or evaluating financial data APIs, it's a practical reference, not just a writeup.

The Real Lesson Wasn't About Stocks

It was about leverage.

AI development tools are changing the economics of building software. The gap between "I have an idea" and "I have a working product" is shrinking fast.

Individual developers can now ship what used to require a full team.

That shift changes who gets to build fintech tools — not just who gets to use them.

FAQs

❓ Is FinView production-ready?
✅ It's primarily educational and experimental, but the architecture is solid enough to serve as a foundation for more advanced trading or research platforms.

❓ Which technologies were used to build it?
✅ Claude Code for development, the EODHD API for market data, and JavaScript/HTML/CSS for the frontend.

❓ Can I build a similar dashboard without AI tools?
✅ Yes. AI mainly reduces development time and automates repetitive implementation — understanding the underlying logic still matters.

❓ Why not just use Finviz?
✅ Finviz is a solid product. This project exists to learn AI-assisted development and build a customizable, open-source alternative you fully control.

❓ Is there a free tier for the EODHD API?
✅ Yes, EODHD offers a free tier suitable for testing screeners and dashboards before scaling to a paid plan.

Final Thoughts

This started with one question: can Claude Code help build a Finviz-style platform from scratch?

The answer was yes.

The bigger realization was this: the future belongs to people who combine AI tools, reliable data sources, and domain expertise. When those three line up, the speed of creation becomes extraordinary.

Explore the code, contribute, or build your own version: FinView on GitHub

Want the data layer behind FinView?
Get real-time and historical market data, fundamentals, and global coverage through one simple API.
→ Start with EODHD

The 10 Best Financial APIs for AI Coding Tools (2026)

Kevin Meneses González — Fri, 19 Jun 2026 08:21:00 +0000

Cursor can scaffold a fintech app in twenty minutes. Claude Code can wire the backend, write the tests, and ship a working build before lunch.

None of that means the app is correct.

If you're:

building a portfolio tracker,
vibe-coding a stock screener,
or shipping a trading dashboard for a client,

the API you plug in decides whether the AI gets it right the first time, or quietly invents endpoints that don't exist.

Your AI coding tool is only as good as the docs it's reading

Here's what actually happens. You open Cursor, paste a financial API's docs link, and ask it to build a price-history endpoint. Half the time it works. The other half, it hallucinates a parameter that was deprecated two years ago, or guesses at a response shape that hasn't matched reality since the provider's last redesign.

That's not a model problem.

It's a documentation problem. Most financial data providers wrote their docs for a human skimming a browser tab, not for a model parsing structure. No llms.txt. No machine-readable OpenAPI spec. No SDK that matches what's actually in the docs.

Developers discover this the expensive way: after the AI ships broken code with confidence, and nobody catches it until the demo.

Coverage matters less than legibility.

In 2026, the financial APIs worth using with an AI coding tool aren't necessarily the ones with the most tickers. They're the ones whose documentation, specs, and SDKs are clean enough that Cursor, Claude Code, Windsurf, or Copilot can generate correct code against them on the first pass.

What to check before you pick one

Before wiring any financial API into an AI-assisted workflow, look for four things:

Machine-readable docs — an llms.txt file, an OpenAPI 3.x spec, or both
An official SDK in your stack's language, not just community wrappers
A real free tier, so the AI can be tested against live responses while you prototype
Predictable pricing, because AI coding tools tend to make you move fast, and fast means more API calls than you planned for

I use EODHD for most of this kind of work, mainly because its OpenAPI spec and AI Agent Skills are built for exactly this. 👉 Get an EODHD key here

Here are the ten that hold up.

1. EODHD — Best all-around for AI-assisted building

EODHD covers 60+ exchanges and 150,000+ tickers, with 30+ years of history on major markets, all returned as clean JSON.

What makes it the strongest pick for coding with AI specifically is the sheer number of on-ramps: an official MCP server with 75 tools, an OpenAPI 3.1 spec covering 74 endpoints, AI Agent Skills built for Claude Code and Codex-style agents, and a ChatGPT assistant trained on its own documentation. When you ask Cursor or Claude Code to build against it, the model has a machine-readable spec to read instead of guessing from prose.

Pros: Broadest AI on-ramp of any provider here, global coverage, fundamentals and technicals under one key, accessible pricing.

Cons: Real-time runs over per-ticker WebSocket rather than ultra-low-latency feeds. US options is a paid add-on.

Pricing: Free tier, then roughly €20–€100/month depending on real-time and intraday access; commercial plans from around €400/month.

Best for: Anyone building a fintech app end-to-end with an AI coding tool and wants one API instead of five.

👉 Grab a free EODHD key and point your AI coding tool at it

2. Massive (formerly Polygon.io) — Best for real-time, latency-sensitive apps

Polygon rebranded to Massive in 2026, though most developers still call it Polygon out of habit. The product underneath is unchanged: tick-by-tick trades, WebSocket streaming, and low-latency US equities and options data.

Its MCP server takes an unusual approach. Instead of one tool per endpoint, it gives the model three composable tools, search, call, and query, that cover the entire API surface and stay in sync automatically as Massive ships new endpoints. For an AI coding tool exploring an API it's never seen, that's a meaningfully shorter learning curve.

Pros: Real-time WebSockets, options with Greeks, a well-designed MCP that scales with the API instead of falling behind it.

Cons: US-centric. Real-time access sits on higher tiers.

Pricing: Free tier with delayed data; paid stock plans roughly $29–$199+/month, with real-time gated to higher tiers.

Best for: Trading dashboards and live-data apps where milliseconds matter.

3. Alpaca — Best for apps that need to act, not just read

Alpaca is a self-clearing broker-dealer, which means it's the rare entry on this list where the AI-built app doesn't just display data, it can place trades.

Alpaca has leaned hard into the coding-tool angle specifically. Its Trading MCP Server and a new Trading CLI are both built from its published OpenAPI specs and explicitly documented to work with Claude Code, Cursor, VS Code, Gemini CLI, and PyCharm. Account creation is free, there's no minimum deposit, and paper trading with $100K in simulated funds means an AI coding tool can build and test a full trading flow without touching real money.

Pros: Free brokerage account, paper trading out of the box, MCP and CLI built around AI coding workflows, equities/options/crypto in one API.

Cons: Full real-time market coverage (beyond the free IEX feed) requires the paid Algo Trader Plus tier. It's brokerage-first, not a general research dataset.

Pricing: Free account and Basic market data; paid tier for full real-time stock and options coverage.

Best for: Apps where the AI needs to read market data and execute on it, with a safe paper-trading sandbox while you build.

4. Financial Modeling Prep — Best for fundamentals-heavy apps

If your AI coding tool's job is reading balance sheets instead of chasing ticks, FMP is the deepest option here. It exposes income statements, ratios, DCF models, filings, transcripts, and institutional holdings across 100+ endpoints, in both REST and WebSocket form.

FMP's documentation is consistently cited as one of the easier financial APIs to scaffold against, partly because the endpoint structure is predictable across asset classes once an AI coding tool learns the pattern from one or two examples.

Pros: Deepest fundamentals and ratios, generous endpoint count, JSON and CSV both supported.

Cons: Real-time data, full global coverage, and earnings transcripts live behind the higher tiers.

Pricing: Free (250 calls/day), Starter around $19/month, Premium around $69/month, Ultimate around $139/month for global coverage and transcripts.

Best for: Valuation tools, equity-research dashboards, and any app where the AI is reasoning about a company's financials.

5. Alpha Vantage — Best for learning the workflow

Alpha Vantage shows up in nearly every roundup of AI-friendly financial APIs, and it earns the spot. It runs an official MCP server, covers 200,000+ tickers across 20+ exchanges, and ships a deep technical-indicator library so the AI doesn't have to compute RSI or MACD by hand.

It's also become the default data backbone behind several open-source multi-agent trading frameworks, which means there's a large body of public code an AI coding tool has effectively already seen during training. That translates into fewer hallucinated calls when you ask it to wire Alpha Vantage into a new project.

Pros: Official MCP, strong indicator library, huge base of public examples and documentation.

Cons: The free tier is heavily rate-limited and you'll hit the wall fast once you start building seriously.

Pricing: Free key with strict limits; premium plans from roughly $50/month.

Best for: Learning the AI-coding-tool-plus-financial-API workflow before committing to a paid provider.

6. Finnhub — Best free tier

Finnhub's free tier is genuinely usable, not a teaser. Sixty calls per minute covers prototyping comfortably, and it includes real-time US quotes, fundamentals, SEC filings, and news with sentiment scores across 60+ global exchanges.

Where it gets interesting for an AI-assisted app is the alternative data: insider sentiment, earnings-call transcripts, lobbying records, and ESG scores, the kind of signal that usually sits behind an expensive institutional feed. There's no single official MCP server, but the docs are clean enough that Cursor or Claude Code can generate a working wrapper from the OpenAPI reference in a few minutes.

Pros: Best free tier in this list, rich alternative data, global coverage.

Cons: No official MCP server, so you're either using a community one or writing your own thin wrapper.

Pricing: Free (60 calls/minute); premium tiers roughly $12–$100/month.

Best for: Side projects and sentiment-driven apps that need to start free and scale gradually.

7. Tiingo — Best lightweight option

Tiingo is the API to reach for when you don't need the firehose. It covers US equities, end-of-day and intraday pricing, fundamentals, crypto, forex, and financial news, with documentation simple enough that an AI coding tool rarely trips over it.

It also ships an MCP server with prompt templates for repeatable analysis tasks, which is a nice touch for a provider this size.

Pros: Clean, predictable docs, decent news coverage, inexpensive paid tiers.

Cons: Narrower than the all-rounders. No deep options or macro coverage, and real-time relies on IEX rather than the full US tape.

Pricing: Free tier for prototyping; low-cost paid plans for higher limits.

Best for: Lightweight US-equity apps and side projects where simplicity beats breadth.

8. Twelve Data — Best for multi-asset, indicator-driven apps

Twelve Data covers stocks, forex, crypto, ETFs, and indices from over 250 exchanges through one consistent API and WebSocket structure, with 100+ technical indicators built in.

The part that matters for AI-assisted coding is consistency. Every endpoint shares the same logic and the same response shape, and an OpenAPI/Swagger spec is published directly for generating client code. That uniformity is exactly what reduces the odds of an AI coding tool inventing a parameter that doesn't exist.

Pros: Clean multi-asset coverage, 100+ indicators, consistent API and WebSocket design, published OpenAPI spec.

Cons: Paid tiers can feel pricier than alternatives offering broader datasets at a similar cost. Fundamentals are thinner than an all-in-one provider.

Pricing: Free Basic plan for US stocks, forex, and crypto; paid plans starting around $29/month.

Best for: Dashboards that mix asset classes and lean on technical indicators.

9. Financial Datasets (financialdatasets.ai) — Best built-for-AI option

Most providers on this list retrofitted AI support onto an API built for humans. Financial Datasets did the opposite: it was designed from the start as a stock market API for AI agents and LLM-powered tools.

It covers 27,000+ tickers and 30+ years of history, including financial statements, equity prices, insider transactions, and full-text SEC filings an AI coding tool can pull directly into context. Five of the most common tickers (AAPL, GOOGL, MSFT, NVDA, TSLA) are free to query, which makes it unusually easy to prototype against before paying for full coverage.

Pros: Purpose-built for AI/LLM consumption, full-text SEC filing access, generous free sandbox on major tickers.

Cons: Younger product than the established players, so the ecosystem of examples and community SDKs is smaller.

Pricing: Free for five major tickers; paid plans for full 27,000+ ticker coverage.

Best for: Agent-style apps that need to reason over filings and statements, not just prices.

10. Intrinio — Best when you outgrow the others

Intrinio is the enterprise option here, and it's upfront about who it's for: fintechs and financial institutions that need licensed, audit-ready data and are willing to pay for it.

What's notable is how directly its marketing addresses AI-assisted building. Intrinio normalizes its data specifically so it plugs into Claude, ChatGPT, and custom models without a transformation layer, and it ships SDKs in Python, Ruby, and JS with sandbox environments for testing. The honest gap: there's no first-party MCP server yet, so an AI coding tool building an agent-style integration needs a custom wrapper rather than a drop-in connection.

Pros: Normalized, audit-ready data built for AI consumption, strong SDKs, broad asset-class coverage including options and ETFs.

Cons: No free production plan, only a limited sandbox. No first-party MCP server. Pricing scales fast once you're past prototyping.

Pricing: Free developer sandbox; production packages typically run from a few hundred to several thousand dollars per year depending on dataset.

Best for: Funded fintech teams that need licensed, compliance-ready data behind an AI-assisted product.

Quick comparison

API	Free tier	AI on-ramp	Best for
EODHD	Yes	MCP + OpenAPI + Agent Skills	All-around fintech apps
Massive	Yes (delayed)	MCP (search/call/query)	Real-time trading dashboards
Alpaca	Yes (paper trading)	MCP + CLI	Apps that place trades
FMP	Yes (250/day)	OpenAPI, REST + WS	Fundamentals & valuation
Alpha Vantage	Yes (limited)	Official MCP	Learning the workflow
Finnhub	Yes (60/min)	OpenAPI reference	Sentiment & alt-data
Tiingo	Yes	MCP with prompt templates	Lightweight US-equity apps
Twelve Data	Yes	OpenAPI spec	Multi-asset, indicator-driven apps
Financial Datasets	Yes (5 tickers)	Built natively for LLMs	Agent-style filing analysis
Intrinio	Sandbox only	Normalized for Claude/ChatGPT	Enterprise, compliance-ready apps

How to pick yours

You're prototyping solo. Start with EODHD or Alpaca, both have real free tiers and AI on-ramps built specifically for coding tools, not retrofitted afterward.

You're building something fundamentals-heavy. FMP or EODHD. Both give an AI coding tool deep, structured financial statements to ground its output instead of inventing numbers.

You're building something that trades. Alpaca for the brokerage layer, Massive if you need lower-latency market data feeding into it.

Wiring one in: what "AI-coding-tool-friendly" actually looks like

The difference between a provider with good AI on-ramps and one without shows up the moment you ask Cursor or Claude Code to build something.

Prompt: "Build a Python function that pulls the last 30 days of daily closing prices for a ticker using EODHD's API and returns them as a list of (date, price) tuples."

Because EODHD publishes an OpenAPI spec, the model reads structure instead of guessing from prose, and the output looks like this on the first try:

import requests
from datetime import date, timedelta

def get_closing_prices(ticker: str, api_key: str, days: int = 30):
    end = date.today()
    start = end - timedelta(days=days)
    url = f"https://eodhd.com/api/eod/{ticker}.US"
    params = {
        "api_token": api_key,
        "from": start.isoformat(),
        "to": end.isoformat(),
        "fmt": "json",
    }
    response = requests.get(url, params=params)
    response.raise_for_status()
    return [(row["date"], row["close"]) for row in response.json()]

No invented parameters. No guessed response shape. That's the entire point of choosing an API with machine-readable docs before you start vibe-coding around it.

From here you can build:

a portfolio tracker that refreshes on a schedule
a screener that filters by price action across a watchlist
a dashboard the AI extends every time you add a new data point

Key takeaways

Coverage matters less than legibility. The API your AI coding tool can read correctly beats the one with more tickers.
Look for llms.txt, an OpenAPI spec, and an official SDK before anything else.
EODHD and Alpaca currently have the most coding-tool-native on-ramps (MCP, CLI, Agent Skills) of the ten covered here.

FAQs

❓ What's the best financial API for AI coding tools like Cursor or Claude Code in 2026?
✅ It depends on what you're building. EODHD has the broadest AI on-ramp for general fintech apps. Alpaca is strongest if the app needs to place trades, not just display data. FMP wins for fundamentals-heavy dashboards.

❓ Do I need an MCP server, or is a regular REST API enough?
✅ A REST API is enough if you're willing to let the AI read the OpenAPI spec and generate the wrapper itself, which works well with providers like FMP or Twelve Data. An MCP server removes that step entirely, which matters more as the app grows.

❓ Which financial API has the best free tier for prototyping with AI?
✅ Finnhub (60 calls/minute) and EODHD both offer free tiers usable for real prototyping, not just a teaser. Alpaca's free paper-trading account is the best option if the app needs to simulate trades.

❓ Can an AI-built app actually place trades, or only read data?
✅ Most of the APIs on this list are read-only. Alpaca is the exception: it's a real brokerage, so an AI-built app can place orders and manage positions through the same API it uses to read market data.

❓ Why does documentation quality matter more than data coverage for AI coding tools?
✅ An AI coding tool generates code from what it can parse. A provider with a clean OpenAPI spec or llms.txt gives the model structure to read instead of prose to guess from, which is the difference between correct code on the first try and a silent hallucination that breaks in production.

The bottom line

The model isn't the bottleneck anymore. The documentation is.

Pick the financial API whose docs your AI coding tool can actually read, and the difference shows up in every function it generates after that.

👉 Start building with the EODHD API here

Looking for technical content for your company? I can help — LinkedIn · kevinmenesesgonzalez@gmail.com

The 7 Best Stock Market APIs for AI Agents in 2026

Kevin Meneses González — Mon, 08 Jun 2026 13:36:20 +0000

The 7 Best Stock Market APIs for AI Agents in 2026

Meta: The 7 best stock market APIs for AI agents in 2026, compared by MCP support, data coverage, and pricing — so your Claude or LLM agent gets reliable data.

Your AI agent is only as smart as the data it can reach.

You can hand it the best model on the market. You can write a perfect system prompt. But if it can't pull live, structured market data, it does the one thing a financial agent must never do: it guesses. And a financial agent that guesses is worse than no agent at all.

The API you pick decides how dumb your agent is

For years, choosing a stock market API came down to four things: coverage, latency, price, and documentation. Those still matter. But agents added a fifth question that quietly outranks the rest. Can the data plug into an agent at all, without you hand-wiring every endpoint?

Most market APIs were never built for that. They were built for humans and dashboards. A developer reads the docs, writes a client, maps each response to a chart. An agent can't improvise that on the fly. It needs a standard way to discover tools and call them, or you end up gluing brittle wrappers together and hoping the model formats the request correctly.

That gap is what Model Context Protocol closed. And it split the market into two camps.

On one side, the AI-native providers shipping official MCP servers your agent connects to directly. On the other, the enterprise backbones that are broad and fast but expect you to bring your own orchestration. Both can be the right answer. It depends on what you're building.

So the real question in 2026 isn't which API has the most data. Plenty have enough.

It's which one your agent can actually use without you babysitting the integration.

How I ranked these

Five things, weighted for agents specifically:

Agent-readiness. Official MCP server, AI skills, or an OpenAPI spec the model can consume.
Structured outputs. Clean JSON the model can reason over without a parsing layer.
Coverage. Equities, fundamentals, news, options, global markets.
Real-time. Whether the agent needs live ticks or end-of-day is enough.
Price. What it costs a solo builder versus a funded team.

Here are the seven that hold up.

1. EODHD — Best all-around for AI agents

EODHD is the closest thing on this list to a single, agent-ready data layer you can build on without stitching five vendors together. It covers 60+ global exchanges, 120,000+ tickers, and 30+ years of history, returning clean JSON with precomputed technical indicators and a built-in screener.

What puts it at number one for agents is the integration surface. EODHD ships an official MCP server with 75 tools that lets Claude, Cursor, and Windsurf query live data in conversation, plus AI Agent Skills with 72 endpoints for Claude Code and Codex, an OpenAPI 3.1 spec for custom GPTs and function calling, and a ChatGPT assistant trained on its docs. No other provider here exposes that many agent on-ramps at once.

Pricing is bundled instead of per-dataset, which matters when an agent touches many data types in one loop.

Pros: Broadest agent toolkit (MCP + Skills + OpenAPI), global coverage, fundamentals and technicals under one key, accessible entry price.
Cons: Real-time runs over WebSocket per ticker rather than ultra-low-latency feeds, so it's not built for HFT. US options is a paid add-on.
Pricing: Free tier, then €19.99/mo (EOD All World), €29.99/mo (+intraday and real-time), €99.99/mo (All-in-One). Commercial from €399/mo.
Best for: Solo builders and teams that want the widest agent-ready dataset under one subscription.

🚀 Start with EODHD

The broadest agent-ready data layer on this list — official MCP (75 tools), AI Skills, and OpenAPI, all under one key.

→ Get your free EODHD API key

2. Alpha Vantage — The default for AI-native research

Alpha Vantage is the name that shows up in almost every "MCP for stock data" roundup, and for good reason. It runs an official MCP server at mcp.alphavantage.co, covers 200,000+ tickers across 20+ exchanges, and ships a deep technical-indicator suite so your agent doesn't have to compute RSI or MACD itself.

It's also the standard data backbone behind open-source agent frameworks like TradingAgents, which simulate a trading desk with multiple LLM analysts. If you're prototyping a multi-agent research system, Alpha Vantage is the path of least resistance.

The catch is the free tier. It exists, which is great for a first build, but it's tightly rate-limited, and you'll hit the wall fast once an agent starts hammering it.

Pros: Official MCP, strong technical indicators, huge ecosystem of docs and examples, AI-native positioning.
Cons: Free tier is heavily throttled. Coverage skews US-and-majors.
Pricing: Free key with strict limits; premium plans from roughly $50/mo.
Best for: AI-native research agents and anyone learning the MCP workflow.

🔗 Site: alphavantage.co

3. Financial Modeling Prep — Best for fundamentals-heavy copilots

If your agent's job is reading balance sheets, not chasing ticks, FMP is the strongest pick. Its MCP server is widely regarded as the king of fundamental analysis, exposing income statements, ratios, DCF models, filings, transcripts, and institutional holdings as agent-callable tools.

FMP says its MCP integration gives agents access to tens of thousands of structured data points, which is exactly what a financial copilot needs to ground its answers instead of inventing them.

It's also one of EODHD's few genuine rivals on breadth-per-dollar, so it's worth a hard look if fundamentals are your core use case.

Pros: Deepest fundamentals and ratios, MCP-ready, generous endpoint count, clean statements data.
Cons: Real-time and global coverage live behind the higher tiers. Some datasets are gated.
Pricing: Free (250 calls/day), Starter ~$19/mo, Premium ~$69/mo, Ultimate ~$139/mo (global + transcripts + 13F).
Best for: Equity-research copilots and valuation agents.

🔗 Site: financialmodelingprep.com

4. Polygon.io (now Massive) — Best for real-time trading agents

Polygon rebranded to Massive in 2026, but developers still call it Polygon. Whatever the name, it's the specialist for speed: tick-by-tick trades, WebSocket streaming, and low-latency US equity and options data.

Its official MCP server is unusually smart. Rather than one tool per endpoint, it gives the model a few composable tools (search, call, query) that cover the entire API surface and stay in sync automatically. That's a clean design for agents that need to roam across many endpoints.

If your agent reacts to intraday moves, this is your data feed. If it runs end-of-day screens, you're paying for latency you won't use.

Pros: Real-time WebSockets, options with Greeks, well-designed MCP, trading-desk-grade infrastructure.
Cons: US-centric. Real-time sits on higher tiers, and cost climbs with it.
Pricing: Free tier with delayed data; paid stock plans roughly $29–$199+/mo, real-time on higher tiers.
Best for: Day-trading agents and live market dashboards where latency is the constraint.

🔗 Site: polygon.io

5. Tradier — Best for agents that actually trade

Most APIs on this list stop at reading data. Tradier goes further. It's a brokerage stack, so an agent can pull quotes and options chains and place orders, check positions, and manage a portfolio through the same connection.

Its docs are unusually forward-leaning for the agent era, with an llms.txt, dedicated LLM resources, and an MCP section that lets connected AI tools access market data, account details, and trade execution. It also supports WebSocket streaming for event-driven agent loops.

The trade-off is scope: it's US-brokerage-centric, not a global research dataset. Real-time data is tied to having a brokerage account.

Pros: Read and act capability, MCP with execution, streaming, strong fit for action-taking agents.
Cons: US-only focus, narrower research data, real-time tied to brokerage access.
Pricing: Free sandbox (delayed); real-time via brokerage account or a low-cost market-data add-on.
Best for: Trading copilots and semi-autonomous execution agents (with guardrails).

🔗 Site: tradier.com

6. Finnhub — Best for alternative data and sentiment

Finnhub punches above its price. The free tier is among the most generous in the category at 60 calls per minute, and it covers 60+ global exchanges, real-time US quotes, fundamentals, SEC filings, and news with sentiment scores.

Where it stands out is alternative data: insider sentiment, earnings-call transcripts, lobbying records, FDA calendars, and ESG scores. Those signals usually live behind expensive institutional feeds. For an agent that reasons about why a stock is moving, that's high-value context.

There's no single official MCP server, but several solid community ones exist (real-time streaming, quotes, fundamentals), so wiring it into Claude is a short job.

Pros: Best-in-class free tier, rich alternative data and sentiment, global coverage.
Cons: MCP is community-built, not official. Premium needed for deeper international data.
Pricing: Free (60 calls/min); Premium roughly $12–$100/mo by tier.
Best for: News-and-sentiment agents and alt-data research workflows.

🔗 Site: finnhub.io

7. Tiingo — Best lightweight option

Tiingo is the clean, developer-friendly choice when you don't need the firehose. It does US equities, end-of-day and intraday pricing, fundamentals, crypto, forex, and genuinely good financial news, with a practical free tier for prototyping and an MCP server with prompt templates for repeatable analysis tasks.

The honest limit: it's narrower than the all-rounders. No deep options, commodities, or macro coverage, and its real-time relies on IEX, which doesn't represent the full US tape.

For a focused US-equity research agent or a side project, that's a fair trade for the simplicity and low price.

Pros: Clean data, strong news, MCP with prompt templates, low cost.
Cons: Narrow scope, IEX-based real-time, no broad options/macro.
Pricing: Free tier; low-cost paid plans for higher limits.
Best for: Lightweight US-equity and news-driven agents.

🔗 Site: tiingo.com

Quick comparison

API	Agent integration	Coverage	Real-time	Free tier	Best for
EODHD	Official MCP (75 tools) + Skills + OpenAPI	Global, 60+ exchanges	WebSocket	Yes	All-around agent data layer
Alpha Vantage	Official MCP	US + majors	Yes	Throttled	AI-native research
FMP	MCP (deep fundamentals)	US→global by tier	Higher tiers	250/day	Fundamentals copilots
Polygon / Massive	Official MCP	US	Yes (low latency)	Delayed	Real-time trading agents
Tradier	MCP + execution	US brokerage	Yes	Sandbox	Agents that trade
Finnhub	Community MCP	Global	Yes (US)	60/min	Alt-data + sentiment
Tiingo	MCP	US-focused	IEX-based	Yes	Lightweight research

How to pick yours

Three honest profiles:

You're a solo builder or prototyping. Start with EODHD for the broadest agent-ready data under one key, or lean on Alpha Vantage's and Finnhub's free tiers while you experiment.

You're building a research or fundamentals copilot. EODHD or FMP. Both give an agent deep, structured fundamentals it can ground its answers in.

You're building a live trading or execution agent. Polygon/Massive for the data feed, Tradier when the agent also needs to place orders.

Wiring one into Claude in a few lines

The reason MCP matters is that connecting a provider stops being a coding project. With EODHD's MCP server, you register it once and your agent can query live data in plain language:

# Register the EODHD MCP server with Claude Code
claude mcp add eodhd \
  -e EODHD_API_KEY=your_api_key_here \
  -- <eodhd-mcp-server-command-from-their-docs>

After that, you don't write endpoint calls. You ask. "Screen US tech stocks with positive EPS under a 50B market cap" becomes a tool call the agent makes on its own, against real data. If you want to see that exact pattern end to end, I walked through letting Claude run a screener and pick stocks in a separate piece.

That's the whole shift. The model does the reasoning. The API tells it the truth.

FAQs

❓ What is the best stock market API for AI agents in 2026?
✅ It depends on the job. For the broadest agent-ready data under one subscription, EODHD is the strongest all-rounder thanks to its MCP server, AI skills, and OpenAPI support. For real-time trading agents, Polygon/Massive; for fundamentals copilots, FMP or EODHD.

❓ Do I need an MCP server, or is a normal API enough?
✅ A normal REST API works if you're willing to write and maintain tool wrappers yourself. An MCP server removes that work: the agent discovers and calls tools through a standard interface, which is faster to build and far less brittle.

❓ Which stock API has the best free tier for AI agents?
✅ Finnhub (60 calls/minute) and Alpha Vantage are the most common free starting points. EODHD and FMP also offer free tiers that are useful for prototyping before you scale up.

❓ Can an AI agent place trades, or only read data?
✅ Most data APIs are read-only. Tradier is the exception here: its brokerage-connected MCP lets a guarded agent place orders and manage positions, not just retrieve quotes.

❓ Do these APIs work with Claude, ChatGPT, and Cursor?
✅ Yes. Providers with MCP servers (EODHD, Alpha Vantage, Polygon, Tradier) connect to Claude, Cursor, and similar tools. EODHD also offers an OpenAPI spec for custom GPTs and a dedicated ChatGPT assistant.

The bottom line

In 2026, the model is rarely the bottleneck. The data is.

Pick the API your agent can actually reach, the one that hands it clean, structured, current market data through an interface it already understands. Get that right and the agent stops guessing and starts reasoning.

If you want the widest agent-ready coverage with the least integration work, EODHD is where I'd start.

🚀 Build your agent on EODHD

Widest agent-ready coverage with the least integration work — MCP, AI Skills, OpenAPI, and a free tier to start.

→ Start building with EODHD

Looking for technical content for your company? I can help — LinkedIn · kevinmenesesgonzalez@gmail.com

I Gave Claude a Stock Screener. Here's What It Picked

Kevin Meneses González — Sun, 07 Jun 2026 11:21:57 +0000

Most "AI picks stocks" demos are fiction.

You ask a chatbot for undervalued companies, it hands you five tickers, and they sound reasonable. AAPL. MSFT. A bank you've heard of. It feels like analysis.

It isn't.

The model is reciting names from its training data. It has no idea what those companies trade at today, what their P/E is this quarter, or whether they're even still profitable. The numbers it quotes are frozen in time, and half of them are made up.

So I ran a different experiment. I gave Claude a real stock screener as a tool, handed it an actual market goal, and let it do the filtering itself.

This is what happened.

If you're:

building AI agents that touch financial data,
automating your own stock research,
or just curious whether an LLM can screen the market without hallucinating,

this one is for you.

The problem with letting an LLM pick stocks

A language model is a text predictor. It is very good at sounding like a financial analyst and very bad at being one.

Ask it for "the cheapest profitable semiconductor stocks" and it will confidently produce a list. But it has no live access to market caps, earnings, or valuations. It is pattern-matching against whatever it absorbed during training, which ended months ago.

Developers discover this the hard way. The picks look fine until you check them and realize the "low P/E" stock the model loved is now trading at three times that, or split, or delisted.

You can't fix this with a better prompt. The data simply isn't in the model.

Claude doesn't need to know the market. It needs a way to query it.

That single shift changes the whole problem.

The moment Claude can call a screener, it stops guessing and starts orchestrating. It decides what to look for, the API decides what's actually true, and Claude reasons over real results instead of inventing them.

The model becomes the analyst. The API becomes the data desk.

The fix: give Claude a screener API as a tool

For the data layer I used the EODHD Screener API. It exposes the entire stock universe behind one endpoint and lets you filter it with simple conditions.

You pass filters and a sort order, and you get structured JSON back. Each result carries fields you can actually screen on:

market capitalization
earnings per share
sector and exchange
dividend yield

No scraping. No unofficial endpoints that break on Mondays. A clean REST call that returns the same shape every time, which is exactly what you need when an LLM is going to consume the output.

That last part matters more than it sounds. Tool use only works if the data coming back is predictable. A screener that returns clean, typed JSON is the difference between an agent that reasons and one that chokes.

If you want to follow along, the screener endpoint and filter fields are documented here.

Wiring the EODHD screener into Claude

The architecture is three pieces: a function that runs the screener, a tool definition that describes it to Claude, and a loop that lets Claude call it.

Start with the function. This is the only part that talks to the market.

import os
import json
import requests

EODHD_API_KEY = os.environ["EODHD_API_KEY"]

def run_screener(filters, sort="market_capitalization.desc", limit=20):
    url = "https://eodhd.com/api/screener"
    params = {
        "api_token": EODHD_API_KEY,
        "fmt": "json",
        "filters": json.dumps(filters),
        "sort": sort,
        "limit": limit,
    }
    r = requests.get(url, params=params, timeout=30)
    r.raise_for_status()
    return r.json()["data"]

Filters are just a list of [field, operator, value] conditions. Profitable tech stocks above a billion in market cap is two lines:

run_screener(
    filters=[
        ["sector", "=", "Technology"],
        ["market_capitalization", ">", 1_000_000_000],
        ["earnings_share", ">", 0],
    ],
    sort="earnings_share.desc",
)

Now describe that function to Claude as a tool. The description is the part most people rush. Don't. This is how the model knows what it can ask for.

import anthropic

client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY from env

screener_tool = {
    "name": "run_screener",
    "description": (
        "Screen US stocks by fundamentals using a live market data API. "
        "Returns matching tickers with fields like code, name, "
        "market_capitalization, earnings_share, sector, and dividend_yield."
    ),
    "input_schema": {
        "type": "object",
        "properties": {
            "filters": {
                "type": "array",
                "description": (
                    "List of [field, operator, value]. Fields include "
                    "market_capitalization, earnings_share, sector, exchange, "
                    "dividend_yield. Operators: '=', '>', '<', '>=', '<='."
                ),
                "items": {"type": "array"},
            },
            "sort": {
                "type": "string",
                "description": "field.direction, e.g. 'earnings_share.desc'",
            },
            "limit": {"type": "integer"},
        },
        "required": ["filters"],
    },
}

The last piece is the loop. Give Claude a goal, let it request the screener, feed the real data back, and let it decide.

goal = (
    "Find profitable, reasonably valued US technology stocks. "
    "Profitable means positive earnings per share. Don't limit yourself to "
    "mega-caps; include mid-caps. Return a shortlist of 5 and explain why "
    "each one made the cut."
)

messages = [{"role": "user", "content": goal}]

while True:
    resp = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=2000,
        tools=[screener_tool],
        messages=messages,
    )
    messages.append({"role": "assistant", "content": resp.content})

    if resp.stop_reason != "tool_use":
        print(resp.content[-1].text)
        break

    results = []
    for block in resp.content:
        if block.type == "tool_use" and block.name == "run_screener":
            data = run_screener(**block.input)
            results.append({
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": json.dumps(data),
            })
    messages.append({"role": "user", "content": results})

That's the entire system. No vector database, no fine-tuning, no agent framework. One function, one tool, one loop.

Here's what happened

I gave Claude the goal above and watched.

The first thing it did was not pick stocks. It picked filters.

It translated "profitable, reasonably valued tech" into a concrete screen on its own:

[
  ["sector", "=", "Technology"],
  ["market_capitalization", ">", 2000000000],
  ["market_capitalization", "<", 50000000000],
  ["earnings_share", ">", 0]
]

Notice the choices. It set a floor and a ceiling on market cap to honor "not just mega-caps." It required positive EPS for "profitable." Nobody told it to do that. It reasoned from the goal to the query.

Then it called the screener, got real tickers back, and narrowed the list with a second pass before writing up its shortlist.

One thing to keep in mind: a screener reads the market as it is today. The exact constituents shift every time you run it, as earnings update and caps move. So this is a representative run, not a fixed list. Run it tomorrow and the names will differ.

Here is the shape of the shortlist it returned and the reasoning it attached to each:

Ticker	Why it made the cut (Claude's reasoning)
FTNT	Positive EPS, sat cleanly inside the requested cap band, software margins
MPWR	Strongest earnings_share in the filtered set; flagged as the highest-quality name
CDW	Profitable, steadier business, included as the "lower-volatility" pick
ZS	Met every filter but Claude caveated it as the most expensive of the five
WDC	Edge case Claude added with a warning that it's cyclical and EPS swings hard

What stood out wasn't the picks. It was the honesty.

Claude flagged its own limits without prompting. It noted that EPS alone doesn't mean a stock is cheap, that it had no forward estimates, and that this was a starting watchlist, not a buy signal.

That's the correct answer. A screener narrows the universe. It does not tell you the future. The model understood the job better than most "AI stock picker" demos pretend to.

Where it fell short: with only fundamental snapshot fields, it couldn't reason about momentum, debt, or recent news. Those need more endpoints. The screener is the front door, not the whole house.

Key takeaways

The model orchestrates, the API decides. Claude is good at turning a vague goal into a precise query. It is not a data source, and the moment you treat it like one, it hallucinates.
Clean JSON is the unlock. Tool use only works when the data coming back is predictable. The screener's structured response is what makes the loop reliable.
Reproducible beats vibes. Run the same prompt twice and you get the same filters against the same live data. That's a system you can audit, not a magic trick.

FAQs

❓ Can AI actually pick stocks?
✅ Not on its own. A language model has no live market data and will invent figures if you let it. Connected to a screener API, it can translate a goal into real filters and reason over real results, which is a very different and far more reliable thing.

❓ What is the best stock screener API for Python?
✅ You want one that returns clean, structured JSON and lets you filter on fundamentals like market cap, EPS, and sector. EODHD's Screener API does this through a single REST endpoint, which makes it a good fit for feeding an LLM.

❓ Do I need an agent framework to build this?
✅ No. The example above is plain Python: one function, one tool definition, one loop. Frameworks add structure when you have many tools, but a single screener doesn't need one.

❓ Is this safe to trade on?
✅ Treat the output as a research shortlist, not a recommendation. A screener narrows thousands of stocks to a handful worth a closer look. The analysis after that is still on you.

Try it yourself

Get a free EODHD key and run the loop above:

👉 Start with the EODHD Screener API here

You'll get:

a single endpoint to screen the full stock universe
filters on market cap, EPS, sector, dividend yield, and more
clean JSON that drops straight into a tool-use loop

The point was never to let an AI gamble on tickers.

It was to stop the model from guessing, and give it something true to work with.

That's the whole trick.

Looking for technical content for your company? I can help — LinkedIn · kevinmenesesgonzalez@gmail.com

Automate Social Media With Python and the Zernio API

Kevin Meneses González — Fri, 05 Jun 2026 10:08:50 +0000

Most people think growing on social media is about better content.

It's not. It's about showing up. Every day. Without missing a beat.

The accounts that win aren't the ones with the smartest takes. They're the ones that posted while everyone else "didn't have time today."

So the real question isn't what do I post?

It's how do I post consistently without it eating my week?

If you're:

a developer building in public,
a founder running content for a SaaS,
or anyone tired of copy-pasting the same post across five tabs,

this is for you.

The problem isn't ideas. It's friction.

Here's what consistent posting actually looks like when you do it by hand.

You write a tweet. You open Reddit, reformat it, pick a subreddit, post. You open LinkedIn, rewrite the tone, post. You remember you wanted to schedule it for tomorrow morning instead, so you don't post — you set a reminder. The reminder fires while you're in a meeting. You skip it.

Multiply that by every day, across every platform.

This is why most people quit. Not because they ran out of things to say. Because the distribution is exhausting.

And if you're a developer thinking "I'll just script it," you hit a second wall fast: every platform has its own API, its own OAuth dance, its own rate limits, its own media specs. Twitter's API works nothing like Reddit's, which works nothing like LinkedIn's.

You wanted to automate posting. Instead you signed up to maintain five integrations forever.

The reframe

You don't have a content problem. You have a plumbing problem.

The fix isn't more discipline. It's removing the manual step entirely — generate the content, schedule it once, and let an API fan it out across every platform.

Two pieces make that possible:

A language model to write fresh posts so you're not recycling the same three lines.
One API that speaks to every platform, so your code doesn't care whether it's posting to Twitter or Reddit.

For the first, GPT-4o-mini is cheap and good enough. For the second, I use Zernio.

Why Zernio

Zernio is a unified REST API for social media publishing. One endpoint replaces the 15 separate integrations you'd otherwise build and babysit.

Pros

One Bearer token, one JSON payload — posts to Twitter/X, Reddit, LinkedIn, Instagram, Facebook and 10+ more platforms.
Schedule, publish now, or bulk-upload — the scheduling logic is built in, not something you write.
No SDK. It's plain REST, so Python's requests library is all you need.
Free first 2 connected accounts, no credit card — enough to ship this whole project for free.

Cons

Pay-per-account after the free tier (graduated: cheaper as you scale).
One account per platform per profile, so multi-client agencies need multiple profiles.

Best for: developers who want to add scheduling and cross-posting to a script or product without becoming a full-time API maintenance engineer.

That last point is the whole pitch. You're not paying for a feature you couldn't build. You're paying to never touch five OAuth flows again.

👉 You can grab a free Zernio key here: zernio.link/kevin-meneses

Building the automation

Here's the plan: a script that generates AI posts and schedules four of them across the coming week — two to Twitter, two to Reddit — in a single run.

Set it up once. Run it Monday. Forget about it.

The full project lives on GitHub if you'd rather clone and run it directly:

git clone https://github.com/Kevinelectronics/social-media-automation.git
cd social-media-automation

1. Install and configure

pip install requests python-dotenv openai

Create a .env file with two keys:

ZERNIO_API_KEY=your_zernio_api_key_here
OPENAI_API_KEY=your_openai_api_key_here

Get the Zernio key free at zernio.link/kevin-meneses, and the OpenAI key at platform.openai.com/api-keys. Then log in to Zernio, open Accounts, and connect your Twitter and Reddit profiles.

2. Set up the clients

import os
import json
import random
import requests
from datetime import datetime, timedelta
from openai import OpenAI
from dotenv import load_dotenv

load_dotenv()

client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

ZERNIO_BASE = "https://zernio.com/api/v1"
HEADERS = {
    "Authorization": f"Bearer {os.getenv('ZERNIO_API_KEY')}",
    "Content-Type": "application/json",
}

TOPICS = [
    "Python automation tips",
    "productivity for developers",
    "shipping side projects",
]

3. Fetch your connected accounts

Zernio gives each connected profile an ID. You need those IDs to tell the API where to post.

def get_accounts():
    r = requests.get(f"{ZERNIO_BASE}/accounts", headers=HEADERS)
    r.raise_for_status()
    return {a["platform"]: a["id"] for a in r.json()}

This returns a clean map:

reddit   → 6a2135f22b2567671ac3e5e4
twitter  → 6a2136552b2567671ac3e855

4. Generate the content

One function for tweets, one for Reddit posts. The Reddit one asks GPT for structured JSON so we get a clean title and body.

def generate_tweet(topic):
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{
            "role": "user",
            "content": f"Write one punchy tweet about {topic}. "
                       f"Max 280 characters. One emoji max, no hashtag spam.",
        }],
    )
    return resp.choices[0].message.content.strip()


def generate_reddit_post(topic):
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{
            "role": "user",
            "content": f"Write a Reddit post about {topic}. "
                       f"Return JSON with keys 'title' and 'body'. No markdown.",
        }],
        response_format={"type": "json_object"},
    )
    return json.loads(resp.choices[0].message.content)

5. Schedule a single post

This is the core call. One payload shape, regardless of platform.

def schedule_post(content, platform, account_id, when, subreddit=None):
    payload = {
        "content": content,
        "platforms": [{"platform": platform, "accountId": account_id}],
        "publishNow": False,
        "scheduledFor": when,
        "timezone": "America/New_York",
    }
    if subreddit:
        payload["platforms"][0]["subreddit"] = subreddit

    r = requests.post(f"{ZERNIO_BASE}/posts", headers=HEADERS, json=payload)
    r.raise_for_status()
    return r.json()["id"]

That's the entire integration. No OAuth handling in your code, no per-platform branching beyond a subreddit field. Zernio normalizes the rest.

6. Schedule the whole week

Loop through four slots, spaced across seven days, alternating platforms.

def schedule_week(accounts):
    start = datetime.now()
    plan = [("twitter", 0), ("reddit", 2), ("twitter", 4), ("reddit", 6)]

    for platform, day_offset in plan:
        when = (start + timedelta(days=day_offset)).replace(
            hour=10, minute=0, second=0, microsecond=0
        ).isoformat()
        topic = random.choice(TOPICS)

        if platform == "twitter":
            content = generate_tweet(topic)
            post_id = schedule_post(content, "twitter", accounts["twitter"], when)
        else:
            post = generate_reddit_post(topic)
            content = f"{post['title']}\n\n{post['body']}"
            post_id = schedule_post(
                content, "reddit", accounts["reddit"], when, subreddit="learnprogramming"
            )

        print(f"✅ {platform:8} | {when} | ID: {post_id}")


if __name__ == "__main__":
    print("🔗 Connecting to Zernio...")
    accounts = get_accounts()
    print("🤖 Generating content and scheduling posts...\n")
    schedule_week(accounts)
    print("\n🎉 Done. Check your Zernio dashboard.")

Run it:

python main.py

And the output:

🔗 Connecting to Zernio...
🤖 Generating content and scheduling posts...

  ✅ twitter  | 2025-06-04T10:00:00 | ID: 6a2142f2d786bdfc96598f5b
  ✅ reddit   | 2025-06-06T10:00:00 | ID: 6a2143aad786bdfc96598f6c
  ✅ twitter  | 2025-06-08T10:00:00 | ID: 6a2144bbd786bdfc96598f7d
  ✅ reddit   | 2025-06-10T10:00:00 | ID: 6a2145ccd786bdfc96598f8e

🎉 Done. Check your Zernio dashboard.

Four posts. A full week. One command.

Make it yours

The script is a skeleton on purpose. Three things to change:

Topics. Edit the TOPICS list to your niche. Trading, design, devops, parenting — whatever you actually post about.

Frequency. The plan list controls how many posts go out and when. Add slots, change the hours, push it to daily.

Platforms. Zernio handles LinkedIn, Instagram and Facebook too. Add a line to the plan with "linkedin" and the matching account ID, and the same schedule_post function just works — no new integration.

From this base you can build:

a content calendar that refills itself every Sunday,
a product that lets your users schedule across platforms,
a cron job on a cheap VPS that runs the whole thing while you sleep.

Key takeaways

Consistency beats brilliance on social media, and consistency is automatable.
The hard part of automation isn't AI content — it's cross-platform plumbing.
One unified API removes that plumbing, so a complete scheduler fits in ~80 lines of Python.

You don't need a marketing team. You need a script and an API that does the boring part.

The complete, runnable code is on GitHub: github.com/Kevinelectronics/social-media-automation.

Get the Zernio API key

To run this, you'll need a Zernio account. The free tier covers your first 2 connected accounts with full API access and no credit card — enough to ship this entire project for free.

👉 Get your free Zernio key here

Connect Twitter and Reddit, drop in your keys, and you'll have a week of posts scheduled before your coffee's cold.

FAQs

❓ Is there a free social media posting API?
✅ Yes. Zernio's free tier includes your first 2 connected accounts with unlimited posts and full REST API access, no credit card required. That's enough to build and run this Python automation end to end.

❓ Can I schedule posts to multiple platforms with one API call?
✅ Yes. Zernio accepts a platforms array in a single request, so one call can target Twitter, Reddit, LinkedIn and more at once. You send one JSON payload and it handles each platform's formatting.

❓ Do I need an SDK to use Zernio with Python?
✅ No. Zernio is a plain REST API with Bearer authentication, so Python's built-in-feel requests library is all you need. No vendor SDK to install or keep updated.

❓ Which platforms does Zernio support?
✅ Twitter/X, Reddit, LinkedIn, Instagram, Facebook, and around ten more including YouTube, TikTok, Threads, Pinterest and Bluesky — all through the same endpoint.

Looking for technical content for your company? I can help — LinkedIn · kevinmenesesgonzalez@gmail.com

DEV Community: Kevin Meneses González

Best Stock Market API for Python Developers (2026)

Scraping Works Until It Doesn't

The Real Problem Is Infrastructure, Not Data

What to Actually Look For

Getting Stock Data in Python: A Working Example

Comparing the Top Stock Market APIs for Python

1. EODHD — Broad coverage, one API for everything

2. Alpha Vantage — Good for prototyping

3. Massive — Strong for US real-time data

4. yfinance — Fine for personal projects, risky for production

How These Fit Together

Key Takeaways

FAQs

I Let Claude Screen 3,000 Stocks Using the EODHD API — Here's What Made the Cut

The Problem With Most Stock Screeners

Giving Claude a Real Data Source

Building the Screener

What Made the Cut

Skipping the Code: EODHD's Official MCP Server

From Here You Can Build

Turning This Into a Daily Job

Key Takeaways

FAQs

7 Best WhatsApp APIs for Developers in 2026 (Compared)

Why "official" isn't always the right call

TL;DR

1. Zernio — the official API minus the paperwork

2. UltraMsg — fastest unofficial setup

3. Green API — the cheapest way to test an idea

4. WAAPI — one flat price, no surprises

5. Whapi.Cloud — built for groups and channels

6. CodeChat — free, open source, your server

7. Wassenger — built for teams, not just developers

Comparison table

How to choose

FAQs

How LLMs Are Replacing Legacy OCR Workflows

*TL;DR: *

The 200-Bank Problem

The Real Problem Was Never Reading Text

What Is AI Document Processing, Actually

How the Pipeline Actually Works, Step by Step

Why Building This In-House Usually Stalls

The Trend: From Templates to Prompts

What This Costs vs. What It Replaces

Where Unstract Fits

Practical Walkthrough #1: Extracting a Bank Statement

Practical Walkthrough #2: Automating Vendor Invoice Approval

Where This Pays Off: Use Cases by Industry

1. Finance — Multi-bank statement reconciliation

2. Insurance — Underwriting and claims processing

3. Accounting — Accounts payable automation

4. Capital markets — KYC and client onboarding

5. Legal and contracts — Clause and obligation extraction

6. Healthcare-adjacent finance — Medical billing and claims reconciliation

Getting Started, Practically

Key Takeaways

FAQs

How to Backtest a Trading Strategy with Python and EODHD API

TL;DR

The Problem with Free Data

The Fix Is Simpler Than You Think

Setup

Script 1: Fetch Historical OHLCV Data from EODHD

Script 2: SMA Crossover Strategy

Script 3: RSI Mean-Reversion Strategy

Script 4: Performance Metrics (Sharpe, Max Drawdown, Win Rate)

Putting It All Together

FAQs

Before You Ship Your Strategy Live

The 5 Best Insider Trading APIs for Developers in 2026 (Compared)

The reframe: the schema matters more than the coverage

The 5 compared

1. EODHD — best value, bundled with fundamentals

2. sec-api.io — most comprehensive SEC coverage

3. Financial Modeling Prep — cheapest bundled entry

4. Quiver Quantitative — the alternative-data angle

5. edgartools — free, open-source, DIY

Quick comparison

TL;DR: