DEV Community: Kevin Meneses González

Build an AI Financial Agent with EODHD's MCP Server

Kevin Meneses González — Fri, 14 Aug 2026 17:48:59 +0000

Most people building financial AI agents connect four or five APIs by hand.

One for prices. One for fundamentals. One for news. One for earnings dates.

The problem isn't lack of data. It's fragmentation.

If you're:

building a research copilot for equities,
automating pre-earnings screening,
or designing an agent that reasons across price, fundamentals, and sentiment,

this matters.

Here's how to build an AI financial agent that pulls all four together, using EODHD's financial data API as the backbone.

The Traditional Financial Data API Approach Breaks Down Fast

Here's what building a financial agent usually looks like with a plain REST API.

You write a function to fetch prices. Another to fetch fundamentals. Another for news. Then you write orchestration logic so your agent knows which endpoint to call, in what order, and how to merge the responses into something the model can reason about.

Each new data type means a new wrapper function.

Each wrapper function is a new failure point.

And every time the agent needs to answer a question that spans two data types, like "is this company's fundamentals strong enough to justify holding through earnings," you're the one stitching the context together, not the model.

Developers usually discover this the hard way. The agent works fine in a demo with one data source. Then a real question comes in that needs prices, fundamentals, and news at once, and the whole orchestration layer has to be rebuilt.

The Real Problem Is Context, Not Data

Financial agents don't need more APIs.

They need a way to reach every data type through one consistent interface, so the model can decide what to call and combine it, instead of you hardcoding that logic in advance.

That's what MCP (Model Context Protocol) is built for.

What an MCP Server Changes for Financial Data APIs

MCP (Model Context Protocol) standardizes how an AI model discovers and calls external tools. Instead of you writing a custom wrapper for every endpoint, the model sees a list of available tools with their schemas, and decides which ones to call based on the question it's answering. It's the same underlying idea as Claude function calling, just extended to a whole catalog of tools instead of one function at a time.

For financial data, this matters because a single question rarely maps to a single endpoint.

EODHD ships an official MCP server with over 70 tools covering fundamentals, historical and real-time prices, earnings calendars, news, and sentiment. You point your agent at the server, and it gets access to all of it without you writing a single API wrapper.

Skip the wrapper functions
EODHD's MCP server exposes 70+ financial data tools out of the box, ready for Claude and other AI agents.
→ Get your EODHD API key

Building the AI Financial Agent with EODHD's MCP Server

Let's build an agent that can answer a question spanning multiple data types in a single call: fundamentals, upcoming earnings, and recent price action for a given ticker.

Setup

pip install anthropic

You'll need an EODHD API token and an Anthropic API key. EODHD's MCP server is available as a hosted endpoint, so there's no server to run yourself.

Connecting the agent to EODHD's MCP server in Python

EODHD's MCP server has two versions: v1 takes your API key directly in the URL, v2 uses OAuth 2.1 for clients that support it (like Claude Desktop). For a server-side script like this one, v1 is simpler.

import anthropic

client = anthropic.Anthropic(api_key="YOUR_ANTHROPIC_API_KEY")

EODHD_API_KEY = "YOUR_EODHD_API_TOKEN"

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1500,
    messages=[
        {
            "role": "user",
            "content": (
                "Give me a quick pre-earnings health check on AAPL: "
                "key fundamentals, the next earnings date, and how the "
                "stock has moved over the last month."
            )
        }
    ],
    mcp_servers=[
        {
            "type": "url",
            "url": f"https://mcp.eodhd.com/v1/mcp?apikey={EODHD_API_KEY}",
            "name": "eodhd-mcp"
        }
    ]
)

for block in response.content:
    if block.type == "text":
        print(block.text)

What's actually happening here

The mcp_servers parameter is the whole trick. You're not calling three endpoints and merging the results yourself. You're handing the model a connection to EODHD's tool catalog and letting it decide what it needs.

For this one prompt, the model will typically:

Call a fundamentals tool to pull margins, revenue growth, and valuation ratios
Call an earnings calendar tool to find the next reporting date
Call a historical prices tool to compute the recent price move

Three tool calls, one conversation, zero orchestration code written by you.

Reading the response

The API returns a mix of content blocks: text for the model's answer, mcp_tool_use for each tool it called, and mcp_tool_result for the raw data. If you want to inspect what the agent actually pulled (useful for debugging or logging), filter by block type instead of assuming a fixed order:

tool_calls = [
    {"name": b.name, "input": b.input}
    for b in response.content
    if b.type == "mcp_tool_use"
]

for call in tool_calls:
    print(call["name"], call["input"])

This is worth doing early. It shows you exactly which tools the model reached for, which helps you spot when it's calling something unnecessary or missing a data type your prompt implied.

Scoring Stock Opportunities with EODHD's Financial Data API

The MCP agent above decides on its own which EODHD tools to call. That's convenient, but it also hides what's happening. If you want to actually understand (and customize) the logic behind "which stocks look like good opportunities," it helps to call the same EODHD endpoints directly and build the scoring yourself.

This is also useful if you want a scheduled script that scans the market every morning instead of waiting for you to ask a chat agent.

Let's build that: a short pipeline that pulls candidates from the Screener API, pulls fundamentals and recent price action for each one, checks the news sentiment, and combines all of it into a single opportunity score.

Step 1: Shortlist candidates with the Screener API

Instead of pulling fundamentals for thousands of tickers, start narrow. The Screener API filters the entire market down to a shortlist in one request.

import requests

API_TOKEN = "YOUR_EODHD_API_TOKEN"

def get_candidates():
    url = "https://eodhd.com/api/screener"
    params = {
        "api_token": API_TOKEN,
        "sort": "market_capitalization.desc",
        "filters": '[["market_capitalization",">",1000000000],'
                   '["exchange","=","us"],'
                   '["sector","=","Technology"]]',
        "limit": 20,
        "fmt": "json",
    }
    response = requests.get(url, params=params)
    return response.json()["data"]

candidates = get_candidates()
tickers = [c["code"] for c in candidates]
print(tickers)

This pulls US tech stocks above $1B market cap, sorted by size. Swap the filters for whatever criteria define a "good price" to you: low P/E, high dividend yield, positive EPS growth, or a 52-week low signal.

Step 2: Pull fundamentals for each candidate

Once you have a shortlist, fetch the fundamentals for each ticker. This is where you check whether the price is actually backed by solid financials, not just cheap for a reason.

def get_fundamentals(symbol):
    url = f"https://eodhd.com/api/fundamentals/{symbol}.US"
    params = {"api_token": API_TOKEN, "fmt": "json"}
    data = requests.get(url, params=params).json()

    highlights = data.get("Highlights", {})
    return {
        "pe_ratio": highlights.get("PERatio"),
        "peg_ratio": highlights.get("PEGRatio"),
        "profit_margin": highlights.get("ProfitMargin"),
        "eps_growth": highlights.get("EPSEstimateNextYear"),
    }

Step 3: Check recent price action

Fundamentals tell you if a company is healthy. Price history tells you if the market has already priced that in, or if there's a gap worth paying attention to.

import pandas as pd
from datetime import date, timedelta

def get_price_trend(symbol):
    url = f"https://eodhd.com/api/eod/{symbol}.US"
    params = {
        "api_token": API_TOKEN,
        "period": "d",
        "order": "d",
        "from": (date.today() - timedelta(days=90)).isoformat(),
        "fmt": "json",
    }
    prices = requests.get(url, params=params).json()
    df = pd.DataFrame(prices)

    last_close = df.iloc[0]["close"]
    month_ago_close = df.iloc[21]["close"] if len(df) > 21 else df.iloc[-1]["close"]
    change_pct = ((last_close - month_ago_close) / month_ago_close) * 100

    return {"last_close": last_close, "change_30d_pct": round(change_pct, 2)}

A stock with strong fundamentals that just dropped 15% in a month is a very different opportunity than one that already ran up 40%.

Step 4: Read the news sentiment

Price and fundamentals don't tell you why a stock moved. Sentiment fills that gap, and it's often what separates a real opportunity from a value trap.

def get_sentiment(symbol):
    url = "https://eodhd.com/api/sentiments"
    params = {
        "s": f"{symbol}.US",
        "api_token": API_TOKEN,
        "from": (date.today() - timedelta(days=14)).isoformat(),
        "fmt": "json",
    }
    data = requests.get(url, params=params).json()
    entries = data.get(f"{symbol}.US", [])
    if not entries:
        return {"avg_sentiment": None}

    avg = sum(e["normalized"] for e in entries) / len(entries)
    return {"avg_sentiment": round(avg, 3)}

Step 5: Combine everything into a single score

This is the part a raw API can't do for you. Each endpoint gives you one dimension. Deciding what a "good opportunity" means is a judgment call, and it belongs in your code, not buried in someone else's black-box score.

def score_opportunity(symbol):
    fundamentals = get_fundamentals(symbol)
    price = get_price_trend(symbol)
    sentiment = get_sentiment(symbol)

    score = 0

    if fundamentals["pe_ratio"] and fundamentals["pe_ratio"] < 25:
        score += 1
    if fundamentals["profit_margin"] and fundamentals["profit_margin"] > 0.10:
        score += 1
    if price["change_30d_pct"] < -5:
        score += 1
    if sentiment["avg_sentiment"] and sentiment["avg_sentiment"] > 0.15:
        score += 1

    return {
        "symbol": symbol,
        "score": score,
        **fundamentals,
        **price,
        **sentiment,
    }

results = [score_opportunity(t) for t in tickers]
ranked = sorted(results, key=lambda r: r["score"], reverse=True)

for r in ranked[:5]:
    print(r["symbol"], "score:", r["score"], "| P/E:", r["pe_ratio"],
          "| 30d change:", r["change_30d_pct"], "%",
          "| sentiment:", r["avg_sentiment"])

Four data points, one loop, one ranked list. Reasonable valuation, healthy margins, a recent dip, and improving sentiment together are a much stronger signal than any one of them alone.

This scoring logic is intentionally simple. You'll want to weight it differently depending on your strategy: a value investor cares more about P/E and margins, a swing trader cares more about the price drop and sentiment shift. The point is that the four EODHD endpoints give you the raw material, and the decision logic is yours to tune.

None of this is financial advice. It's a framework for turning scattered data into a shortlist worth researching further, not a signal to buy.

Wiring this back into the agent

Once this scoring pipeline works as a standalone script, you can expose it to your MCP agent as a custom tool alongside EODHD's built-in ones. Then a prompt like "find me tech stocks that dropped recently but still look fundamentally solid" runs your exact scoring logic instead of the model guessing at criteria on its own.

That's the real advantage of combining direct API calls with MCP: you get full control over the decision logic, and the model still handles the natural-language layer on top of it.

This is, in practice, what it means to build an AI financial agent: not a single clever prompt, but a data layer you trust plus a model that knows when to reach for it.

From Here You Can Build

Once the agent can combine fundamentals, prices, earnings, and news on its own, the use cases stop being single-question demos.

pre-earnings screeners that flag weak fundamentals before a reporting date
sentiment-aware alerts that combine news tone with price moves
research copilots that answer multi-part questions without a rigid script

None of this requires new wrapper code. It requires better prompts and, occasionally, a narrower system prompt telling the agent which tools to prioritize.

Key Takeaways

Traditional REST integrations force you to write and maintain orchestration logic for every combination of data types
MCP moves that orchestration into the model itself, so one conversation can span fundamentals, prices, earnings, and news
Combining the Screener, fundamentals, price, and sentiment endpoints directly gives you full control over what counts as a "good opportunity," instead of relying on a single metric
EODHD's MCP server gives you 70+ financial tools without writing a single wrapper function, and you can add your own scoring logic as a custom tool on top of it

FAQs

❓ Do I need to run my own MCP server to use EODHD's tools?
✅ No. EODHD hosts the MCP server, so you connect to it with a URL and your API token, the same way you'd call a REST endpoint.

❓ Does MCP replace the EODHD REST API?
✅ No, it sits on top of it. The REST API still powers every tool call, MCP just gives the AI model a structured way to discover and use those endpoints without custom wrapper code.

❓ Can I limit which tools the agent has access to?
✅ Yes. You can scope the system prompt or restrict the conversation to specific tool categories if you don't want the agent reaching for endpoints outside a given use case, like keeping it to fundamentals and earnings only.

❓ Is this approach only useful with Claude?
✅ No. MCP is an open protocol, so EODHD's server works with any MCP-compatible client, including ChatGPT, Cursor, and Windsurf, not just Claude.

❓ How many API calls does a scan like this use?
✅ It depends on your shortlist size. Each screener request counts as 5 calls, and each fundamentals, price, or sentiment call for a ticker counts as 1. Scanning 20 candidates works out to roughly 65 calls, well within EODHD's free tier for occasional runs.

❓ Can I use this scoring script to automate actual trades?
✅ The script only ranks and prints candidates. Connecting it to a broker's execution API is a separate step, and it's worth adding manual review before any live-money decision, no matter how the shortlist was generated.

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.

Want more content like this?
Python, APIs, fintech, and AI agent tutorials for developers.
→ Visit kevinmeneses.com

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

Best 5 Browser Automation API for AI Agents in 2026

Kevin Meneses González — Thu, 06 Aug 2026 08:04:53 +0000

Every team building browser automation hits the same fork in the road. Manage headless Chrome yourself, or hand the whole problem to an API.

Browserless.io built this category. It turned "run a headless browser at scale" from a DevOps project into a single endpoint.

The question worth asking in 2026 isn't whether Browserless works. It's what actually competes with it, and when one of those alternatives fits your stack better.

If you're:

scraping data at scale,
running AI agents that need to browse the web,
or automating screenshots, PDFs, and testing pipelines,

this comparison is for you.

What a Managed Headless Browser API Actually Needs to Solve

A "headless browser API" sounds simple on paper. Send a URL, get back HTML, a screenshot, or a PDF.

In production, the real problems show up fast:

Browsers crash and leak memory under load
Websites detect and block automated traffic
CAPTCHAs interrupt otherwise working scripts
Sessions need to be debugged when an agent silently fails
Scaling from 10 to 10,000 concurrent sessions breaks naive setups

Every vendor in this space is really selling the same thing: someone else managing that complexity so you don't have to.

The Real Differentiator Isn't the Feature List

Most comparison articles line up checkboxes. Stealth mode, yes or no. CAPTCHA solving, yes or no. Proxy rotation, yes or no.

That's not where these tools actually diverge.

The real differentiator is production reliability, plus how a vendor responds when something breaks at 2am on a Sunday. A landing page can promise stealth browsing. It can't promise someone will answer your support ticket in twenty minutes.

That's the lens for this comparison.

5 Headless Browser APIs Worth Evaluating in 2026

1. Browserless.io

Browserless.io provides managed headless browser infrastructure built specifically for developers and engineering teams.

Its core offerings are BrowserQL (a stealth-first query language for bot bypass and structured data extraction), Browsers as a Service (a pooled cloud of Chromium, Firefox, and WebKit instances compatible with Puppeteer and Playwright), and straightforward REST APIs for screenshots, PDFs, and scraping. It also solves CAPTCHAs automatically, including reCAPTCHA, hCaptcha, and Cloudflare Turnstile.

The platform abstracts away browser lifecycle management: version updates, memory leaks, scaling, and detection avoidance become one API endpoint instead of a maintenance burden.

Pros

BrowserQL gives you stealth and structured extraction without hand-rolling anti-detection logic
Supports Puppeteer, Playwright, and Selenium with a one-line connection change
Self-hosting is available (through providers like Sliplane) if you want fixed infrastructure costs instead of per-unit billing

Cons

Paid plans range from $25/month (Prototyping) up to $350/month (Scale), and cost can climb quickly with concurrency
The free tier caps out at 1,000 units/month, which disappears fast in a real scraping job

Best for: teams that need full headless browser control (Puppeteer or Playwright scripts, PDF generation, multi-page navigation flows) without building that infrastructure themselves.

Looking for technical content that explains your API like this?
I write educational, SEO-optimized articles for developer tools and infrastructure companies, not marketing fluff.
→ Let's talk on LinkedIn

2. Hyperbrowser.ai

Hyperbrowser.ai positions itself as internet infrastructure built specifically for AI agents rather than general-purpose scraping.

It provides instant, scalable browser infrastructure with built-in CAPTCHA solving, proxy management, and anti-bot detection, plus HyperAgent, an AI-native automation framework that layers natural language commands (page.ai(), page.extract()) on top of standard Playwright.

Pros

Built around agent workflows from day one, not scraping retrofitted for agents
Falls back to regular Playwright when you don't need the AI layer, so you're not locked into one paradigm
Backed by Y Combinator, Accel, and SV Angel, with active engineering hiring

Cons

Small team (4 employees as of 2026), which means less dedicated support bandwidth than a larger vendor
Younger platform with a smaller track record at large scale compared to Browserless

Best for: teams building AI agents that need to browse and extract data using natural language instructions instead of brittle selector-based scripts.

3. Steel.dev

Steel.dev is an open-source browser API purpose-built for AI agents, with a clear focus on speed and observability.

Its published lifecycle benchmark shows Steel completing a create-connect-navigate-release cycle in an average of 0.89 seconds, which the team reports as 1.70x to 8.95x faster than other providers tested under the same conditions. It adds live session viewers, MP4 replays, and Agent Logs, a timeline of every click, navigation, and scroll an agent takes.

Pros

Open source, so you can self-host and audit exactly what's running
Agent Logs and session replay make debugging failed automation runs far less painful
Fast session starts matter directly for agent workloads that spin up and tear down browsers repeatedly

Cons

Early-stage company; smaller team and less enterprise track record than Browserless
Fewer built-in integrations outside the core Puppeteer/Playwright/Selenium compatibility layer

Best for: teams that want an open-source, self-hostable browser API and care about debugging tools as much as raw automation.

4. Surfsky.io

Surfsky.io is built around one specific problem: bypassing advanced anti-bot systems that block most standard headless browser setups.

It targets CAPTCHA, WAF, and bot-detection bypass as its primary differentiator, positioning itself directly against Browserbase and ZenRows on bypass reliability rather than general feature parity. The platform offers an API-first architecture designed to integrate with existing automation frameworks.

Pros

Purpose-built for the hardest scraping targets: sites with aggressive anti-bot protection
Cloud-based infrastructure designed for scale without manual proxy management
API-first design means less glue code to plug it into an existing pipeline

Cons

Narrower focus than Browserless. Less useful if PDF generation, screenshots, or general testing automation are your primary use case
Smaller, less established brand compared to the other tools on this list

Best for: teams whose main blocker is bypassing sophisticated bot detection on specific high-value targets, not general-purpose browser automation.

5. Gaffa

Gaffa is a lightweight API for web scraping and browser automation aimed at developers who want one API call instead of managing browser infrastructure.

It handles residential proxies, scaling, and failure recovery internally, and supports actions like scrolling, clicking, and extracting page data as images, Markdown, HTML, or LLM-structured JSON. Credits are charged for actual browser execution time and bandwidth, with no fixed infrastructure costs.

Pros

Simple, single-endpoint design with low setup overhead
Native output as clean Markdown or JSON, useful for feeding LLM and RAG pipelines directly
Pay-for-usage pricing with no fixed infrastructure fees

Cons

Indie, early-stage project with a very small team, so support and roadmap velocity are unproven at scale
Fewer public case studies or production references compared to established vendors

Best for: solo developers or small teams that want a minimal, low-overhead scraping and automation API without evaluating a full enterprise platform.

Headless Browser API Comparison Table

Tool	Team size	Pricing model	Stealth / anti-bot	Self-host option	Best for
Browserless.io	Established	$25 to $350/month tiers, free tier (1,000 units)	BrowserQL stealth mode, CAPTCHA solving	Yes (via Sliplane, ~€9/month)	Full Puppeteer/Playwright control at production scale
Hyperbrowser.ai	~4 employees	Usage-based, free to start	Built-in CAPTCHA + anti-bot	No	AI-agent-native automation with natural language commands
Steel.dev	Early-stage	Open source, self-hosted or managed	Stealth browsing patches	Yes (open source)	Self-hosted browser API with strong debugging tools
Surfsky.io	Small	Not publicly listed	Advanced anti-bot / WAF bypass	No	Bypassing aggressive bot detection on specific targets
Gaffa	Indie / micro-team	Pay-per-execution, no fixed cost	Stealth mode with residential proxies	No	Solo devs needing a simple, low-overhead API

Key Takeaways

Browserless.io remains the safest default pick if you need full browser control (Puppeteer, Playwright, PDF generation) at production scale, backed by a mature platform and a self-hosting path.
If your workload is AI-agent-specific, Hyperbrowser.ai and Steel.dev are worth testing for their agent-native tooling and debugging features.
If bot detection bypass is your single hardest problem, Surfsky.io is a narrower but more targeted option than a general-purpose platform.

The smaller vendors on this list (Hyperbrowser, Steel.dev, Surfsky.io, Gaffa) can move faster on support and roadmap requests precisely because they're small. That's a real advantage, but it comes with less production history than Browserless.io has built over time.

For most teams evaluating a headless browser API in 2026, that trade-off, and not the feature list, is the decision that actually matters.

Building a developer tool in this space?
I create technical, SEO-optimized content like this comparison for API and infrastructure companies. If that's useful for your product, let's talk.
→ Connect with me on LinkedIn

More technical writing and projects:
→ kevinmeneses.com

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

How to Build an AI Trading Bot with Claude and the EODHD API

Kevin Meneses González — Wed, 05 Aug 2026 13:52:53 +0000

Most trading bots are just if-statements wearing a costume.

RSI below 30, buy. Moving averages cross, sell. That works fine until the market does something the rules didn't anticipate, and then the bot keeps executing the same logic anyway, because it can't actually think.

If you're:

building AI agents that need to reason over structured data,
exploring what LLMs can actually do in a finance context,
or evaluating how to combine market data with automated decision-making,

this is for you.

The problem with rule-based bots

A rule-based bot doesn't understand the market. It pattern-matches against a formula someone wrote months ago.

Earnings surprise. A sudden news event. A sector rotation nobody coded for. The bot has no way to account for any of it, because it was never built to interpret context, only to check conditions.

Developers usually discover this the hard way. They backtest a strategy, watch it perform well on historical data, deploy it, and then spend the next few months tweaking thresholds every time the market shifts. The bot isn't wrong. It's just blind.

There's also the data problem underneath all of this. Plenty of hobby projects lean on scraped Yahoo Finance endpoints or free tiers that cap out fast, and both tend to fail exactly when you need them most.

The real problem

A trading bot doesn't need more rules. It needs reasoning.

That's a different kind of system entirely. Instead of "if X then Y," you want something closer to "given this data, what would a reasonable analyst conclude, and why."

Large language models are good at exactly that kind of contextual judgment, as long as you feed them clean, structured data instead of asking them to guess.

The stack

This tutorial combines two pieces:

EODHD API for market data. End-of-day prices, real-time quotes, fundamentals, and historical data through a single REST interface, without maintaining scrapers that break every time a website changes its HTML.

Claude for the reasoning layer. Given a snapshot of price action, volume, and basic fundamentals, Claude produces a structured decision (buy, hold, sell) along with the reasoning behind it, in a format your code can actually parse and act on.

You could swap either piece out. The point isn't "use these exact two tools forever," it's showing how the pattern works so you can adapt it.

Want reliable market data without building your own scraping layer?
EODHD covers over 150,000 tickers with a generous free tier and no rate-limit surprises mid-project.
Get your free EODHD API key →

Setting up

You'll need two API keys: one from EODHD, one from Anthropic.

pip install requests anthropic python-dotenv

Store your keys in a .env file:

EODHD_API_KEY=your_eodhd_key_here
ANTHROPIC_API_KEY=your_anthropic_key_here

Step 1: Pull market data from EODHD

Start with a function that grabs recent price history and a live quote for a given ticker.

import os
import requests
from dotenv import load_dotenv

load_dotenv()
EODHD_KEY = os.getenv("EODHD_API_KEY")

def get_market_data(ticker: str, exchange: str = "US"):
    symbol = f"{ticker}.{exchange}"

    # Last 30 days of end-of-day prices
    eod_url = f"https://eodhd.com/api/eod/{symbol}"
    eod_params = {
        "api_token": EODHD_KEY,
        "period": "d",
        "fmt": "json",
        "order": "d",
    }
    eod_resp = requests.get(eod_url, params=eod_params).json()[:30]

    # Live quote
    quote_url = f"https://eodhd.com/api/real-time/{symbol}"
    quote_params = {"api_token": EODHD_KEY, "fmt": "json"}
    quote_resp = requests.get(quote_url, params=quote_params).json()

    return {
        "ticker": ticker,
        "current_price": quote_resp.get("close"),
        "change_pct": quote_resp.get("change_p"),
        "volume": quote_resp.get("volume"),
        "recent_history": eod_resp,
    }

This gives you a clean payload: current price, percentage change, volume, and 30 days of history. No scraping, no broken HTML selectors.

Step 2: Ask Claude to reason over the data

This is the part that separates it from a rule-based bot. Instead of hardcoding thresholds, you hand Claude the data and ask for a structured judgment call.

import json
from anthropic import Anthropic

client = Anthropic(api_key=os.getenv("ANTHROPIC_API_KEY"))

def get_trading_decision(market_data: dict) -> dict:
    prompt = f"""You are a trading analyst reviewing market data for {market_data['ticker']}.

Current price: {market_data['current_price']}
Change today: {market_data['change_pct']}%
Volume: {market_data['volume']}
Recent 30-day history: {json.dumps(market_data['recent_history'][:10])}

Based on this data, provide a trading decision. Respond ONLY with valid JSON in this exact format:
{{
  "decision": "buy" | "hold" | "sell",
  "confidence": 0.0 to 1.0,
  "reasoning": "2-3 sentence explanation grounded in the data provided"
}}"""

    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=300,
        messages=[{"role": "user", "content": prompt}],
    )

    raw_text = response.content[0].text.strip()
    return json.loads(raw_text)

The key detail here is the response format. Asking for structured JSON, not a paragraph, is what makes this usable in an actual pipeline instead of a chat window.

Step 3: Wire it together

def run_analysis(ticker: str):
    data = get_market_data(ticker)
    decision = get_trading_decision(data)

    print(f"\n{ticker} — Decision: {decision['decision'].upper()}")
    print(f"Confidence: {decision['confidence']}")
    print(f"Reasoning: {decision['reasoning']}")

    return decision


if __name__ == "__main__":
    run_analysis("AAPL")

Sample output:

AAPL — Decision: HOLD
Confidence: 0.62
Reasoning: Price is up 0.8% on below-average volume, suggesting limited
conviction behind the move. Recent history shows consolidation rather than
a clear trend, so waiting for a volume-confirmed breakout makes more sense
than acting now.

That reasoning field is the whole point. You get a decision plus the logic behind it, which you can log, review, and adjust over time. A rule-based bot never gives you that.

Testing it without risking real money

Before connecting this to anything resembling a real account, run it against a paper trading environment.

Alpaca is a solid option here. Its paper trading API mirrors the live trading endpoints exactly, so you can route Claude's decisions through simulated buy and sell orders and see how the strategy would have performed, with fake money and real market conditions.

import alpaca_trade_api as tradeapi

alpaca = tradeapi.REST(
    os.getenv("ALPACA_API_KEY"),
    os.getenv("ALPACA_SECRET_KEY"),
    "https://paper-api.alpaca.markets",
)

def execute_paper_trade(ticker: str, decision: dict):
    if decision["decision"] == "hold":
        print(f"No action for {ticker}, holding position.")
        return

    side = "buy" if decision["decision"] == "buy" else "sell"

    alpaca.submit_order(
        symbol=ticker,
        qty=1,
        side=side,
        type="market",
        time_in_force="day",
    )
    print(f"Paper {side} order submitted for {ticker}.")

Run execute_paper_trade after get_trading_decision and you have a full loop: EODHD for data, Claude for reasoning, Alpaca for execution, all without a single dollar at risk.

This is also where you'd start tracking accuracy. Log every decision, compare it against what actually happened three or five days later, and you'll quickly see whether the reasoning holds up or needs a better prompt.

From here you can build:

a scheduler that runs this analysis daily across a watchlist
a logging layer that scores decisions against actual outcomes
a risk filter that blocks trades below a confidence threshold

Key takeaways

An LLM adds contextual reasoning that fixed rules can't replicate on their own.

Clean, reliable market data matters more than people expect. Claude is only as good as what you feed it, and EODHD removes the guesswork of scraping or rate-limited free APIs.

This is a starting point, not a production system. Position sizing, stop losses, and proper risk management live outside the scope of this tutorial, and skipping them before going live is how paper gains turn into real losses.

FAQs

❓ Do I need trading experience to build this?
✅ No. You need basic Python and an understanding of what a buy, hold, or sell decision means. The reasoning comes from Claude, not from you having to encode strategy logic manually.

❓ Is this real algorithmic trading?
✅ It's a form of it, specifically an LLM-assisted decision layer rather than a pure quantitative model. Traditional algo trading uses fixed mathematical rules; this approach adds a reasoning step on top of the data.

❓ Can I connect this to a real brokerage account?
✅ Technically yes, since Alpaca's live and paper APIs share the same structure. Don't, until you've backtested extensively and added proper risk controls. This tutorial is educational, not a plug-and-play trading system.

❓ Does EODHD provide real-time data or only end-of-day?
✅ Both. EODHD offers end-of-day historical data going back years, plus real-time and delayed quotes depending on your plan, which is why it works for both the historical context and the live price checks in this tutorial.

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: Kevin Meneses González

Building something with market data?
EODHD gives you 30+ years of historical data, real-time quotes, and fundamentals in one API.
Start free with EODHD →

More tutorials like this
I write about fintech APIs, Python, and AI agents every week.
Read more on kevinmeneses.com →

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

7 Best OCR Tools with AI in 2026 (Compared)

Kevin Meneses González — Tue, 04 Aug 2026 08:18:47 +0000

Every "best OCR tool" article online is one of two things: a vendor's own product page, or a listicle that copied the same five names from another listicle. Neither tells you which tool actually fits what you're building.

This one does.

If you're:

digitizing scanned paperwork for a small team,
building a document pipeline that needs to run unattended,
or deciding whether an OCR API is worth the integration work,

this comparison is built around those three decisions, not around which vendor has the biggest marketing budget.

OCR still fails in predictable ways

Optical character recognition has gotten good enough that most people assume it just works now. Feed it a document, get clean text back.

That assumption breaks down fast on three kinds of input: a photo taken at an angle under bad light, a PDF with a table instead of plain paragraphs, and anything with handwriting. Vendor pages rarely mention this. They quote a single accuracy number, usually from a clean, high-resolution test document that looks nothing like what actually lands in most inboxes.

The other thing nobody advertises up front: uploading a document to a free online OCR tool means sending its content to someone else's server. For a random screenshot, that's irrelevant. For an ID, a payslip, or a signed contract, it's the first question you should be asking, not the last.

The real decision isn't "which OCR is best"

It's whether you need a one-off web tool, an API you call from code, or something self-hosted that never leaves your machine.

That single choice determines cost, speed, and how much control you have over where your data goes, more than any accuracy benchmark does.

Approach	How it works	Best for	Typical cost
Web tool (Adobe, Google Lens)	Upload a file, it's processed on the vendor's server, download the result	One-off use, low volume	Free with limits, or a paid plan for full features
API (Google Vision, Mistral OCR, Mindee, Unstract)	You call it from your own app or pipeline	Volume, automation, product integration	Per page or per call, usually a few cents
Self-hosted (Tesseract)	Runs on your own machine or server, nothing gets uploaded	Full data control, no recurring fee	Free, but you handle setup and tuning

Once you know which lane you're in, picking between tools gets a lot faster. Here are the 7 worth knowing.

1. Google Cloud Vision API: the default cloud OCR

Vision API is Google's general-purpose image analysis service, and text detection is one feature inside it, alongside label and object detection.

Google Vision is built for general OCR and image analysis, while specialized services like AWS Textract focus on structured document extraction such as tables and invoices. That distinction matters: Vision reads text well, but it returns raw text and bounding boxes, not structured fields. Pricing runs on a free tier of 1,000 images a month, then roughly $1.50 per 1,000 images for standard text detection, with a separate and considerably more expensive Document AI product for forms and tables.

Pros

Backed by Google's infrastructure, so uptime and language coverage are strong
Cheap at low-to-mid volume for plain text extraction
Well-documented Python SDK

Cons

Billing is split across features and products, and it's easy to underestimate cost once you add Document AI for tables
No built-in structured output for invoices or forms without the pricier add-on

Best for: developers who need reliable text extraction from images or scans and are comfortable managing a GCP project.

cloud.google.com/vision

2. Mistral OCR: the AI-native option built for RAG pipelines

Mistral built its OCR model specifically around modern document AI use cases: feeding clean, structured text into retrieval pipelines and AI agents.

Mistral OCR handles complex document elements including interleaved images, mathematical expressions, tables, and layouts like LaTeX formatting, and supports over 170 languages. It's priced per page rather than per token, which keeps costs predictable at scale, and a self-hosted deployment option exists for organizations that need to keep sensitive documents off shared infrastructure.

Pros

Markdown output with reconstructed tables, ready to drop into a RAG pipeline
Flat per-page pricing instead of token-based billing
Self-hosting available for privacy-sensitive workloads

Cons

Newer product, so community resources and third-party tutorials are thinner than Google's or AWS's
Overkill if you just need plain text from a handful of documents

Best for: teams building AI agents or RAG systems that need documents converted into clean, structured markdown.

mistral.ai

3. ABBYY: the enterprise veteran

ABBYY has been in document recognition longer than most of the other names on this list, and it shows in how many languages and document types it handles out of the box.

Its FineReader Engine SDK targets developers building OCR into desktop or server applications, while FineReader PDF is the consumer-facing product for individuals converting scans into editable files. Pricing for the SDK is quote-based and depends on volume and deployment, so there's no flat number to point to. The consumer product runs in the low hundreds of dollars per year.

Pros

Recognition quality across a very wide set of languages and scripts
Long track record in regulated industries like finance and legal

Cons

SDK pricing requires a sales conversation, which slows down evaluation for smaller teams
Feels dated next to API-first competitors built around REST and JSON from day one

Best for: enterprises with existing document workflows in legal, finance, or healthcare that need broad language support and are willing to go through a sales process.

abbyy.com

4. Mindee: developer-first document extraction

Mindee sits closer to Mistral than to Google: it's built for developers who want structured fields back, not just raw text.

It ships pre-trained models for invoices, receipts, IDs, and bank statements, so instead of parsing raw OCR output yourself, you get named fields like supplier name or total amount directly in the response. Pricing is usage-based, with a free tier for testing and a per-page rate that scales down as volume increases.

Pros

Pre-built models for common document types cut integration time significantly
Clear, transparent per-page pricing published on the site
EU-based, which matters for teams with GDPR requirements

Cons

Less flexible than a general OCR API if your documents don't fit the pre-trained categories
Custom document types require more setup than the ready-made models

Best for: teams processing a specific, repeatable document type (invoices, receipts, IDs) who want structured JSON without building their own parsing logic.

mindee.com

5. Unstract: open-source, no-code document pipelines

Unstract takes a different approach entirely: instead of a fixed OCR model, you define what you want extracted using prompts, test them against sample documents, then deploy the result as an API or an automated pipeline.

It's open source under AGPL-3.0, available self-hosted through Docker, as a managed cloud service, or on-premise for enterprise deployments. Its OCR preprocessor, LLMWhisperer, is built to preserve the layout of tables and columns before handing the text to an LLM, which is exactly the kind of detail that matters when a document isn't just paragraphs of text.

Pros

Prompt-based extraction adapts to new document layouts without retraining
Open-source option removes vendor lock-in entirely
Built-in connectors for ingesting from S3, Dropbox, or a data lake

Cons

The no-code/prompt-based workflow has a learning curve if you're used to a simple REST call
Best results depend on which underlying LLM you pair it with, which adds a decision on top of the tool itself

Best for: teams that need to extract structured data from varied or changing document layouts without hand-coding a parser for each one.

unstract.com

6. Adobe Acrobat: the one everyone already has

More people search for Adobe's OCR than for any other tool on this list, mostly because Acrobat is already installed somewhere in every office.

OCR only ships in the Pro tier, not the free Reader. It converts scanned files into editable, searchable PDFs and can batch-process folders through Action Wizard. Adobe doesn't publish a specific accuracy figure the way ABBYY does, but it covers 50-plus languages with automatic detection, and the Pro plan runs close to $20 a month.

Pros

Already familiar to most office workers, so there's no learning curve
Batch processing across folders is straightforward
Output stays inside the PDF workflow most teams already use

Cons

No API for automated, high-volume processing, it's a desktop tool
OCR is locked behind the paid Pro tier, not available in free Reader

Best for: individuals or small teams doing occasional OCR inside a document workflow they already run through Acrobat.

adobe.com/acrobat

7. Tesseract: free, self-hosted, no data leaves your machine

Tesseract is the answer for anyone who read the privacy section above and decided nothing should leave their own infrastructure.

It's open source under the Apache 2.0 license, was originally developed at HP and later taken over by Google, and has a fully featured API that can be compiled for a wide range of targets, including Android and iPhone. It supports over 100 languages out of the box and runs entirely on your own hardware. Python developers usually reach it through the pytesseract wrapper.

Pros

Completely free, no per-page or per-call cost ever
Nothing gets uploaded anywhere, which settles the privacy question by design
Actively maintained, wide language support

Cons

Accuracy on messy scans or handwriting lags noticeably behind AI-native APIs
You own the image preprocessing and language-model tuning yourself, that work doesn't disappear, it just moves to you

Best for: developers who need full control over where documents are processed and are willing to handle image preprocessing themselves.

github.com/tesseract-ocr/tesseract

What no one else covers: what happens to your document

Every free online OCR tool works the same way behind the scenes: your file gets uploaded to a server, processed, and the result gets sent back. What happens to the file after that depends entirely on the vendor's retention policy, and most people never check.

Before uploading anything sensitive (an ID, a payslip, a signed contract) to a free web tool, three questions are worth answering:

Does the provider delete the file immediately after processing, or keep it for some retention window? Where are the servers located, which matters for GDPR if you're in the EU and for general data-handling expectations everywhere else? And does the free tier reuse uploaded documents to train future models?

If you can't find a clear answer to those three on the vendor's own site, treat that as the answer. For anything sensitive, either pick a tool with a documented deletion policy or process it locally with Tesseract, where the question doesn't even come up.

Need a technical writer who actually tests the tools?
I write developer-focused comparisons and tutorials for API and document-processing companies, not marketing copy dressed up as content.
→ Connect on LinkedIn

Three things to take away

Volume decides more than accuracy does: below a few hundred documents a month, a free web tool or Tesseract covers it, above that, an API pays for itself in time saved.

The advertised accuracy number is almost never the number you'll get on a bad scan or a handwritten form, budget for that gap when picking a tool for production use.

Privacy isn't a footnote, it's a selection criterion. Know where your document goes before you upload it, not after.

FAQs

What is OCR and what is it used for?
OCR (optical character recognition) extracts text from images or scanned documents so it can be edited, searched, or processed by software. It's used for digitizing paperwork, converting scanned PDFs into searchable files, and automating data entry from invoices, receipts, and forms.

What's the difference between traditional OCR and AI-powered OCR?
Traditional OCR matches character shapes against a fixed pattern library, which struggles with handwriting, unusual fonts, and messy scans. AI-powered OCR uses machine learning models trained on huge datasets, which handles those same cases far better and can also understand document structure like tables and forms.

Is it safe to upload documents to an online OCR tool?
It depends on the provider's data retention policy. Free tools don't always delete files immediately or disclose where they're processed. For sensitive documents, check the vendor's privacy policy first or use a self-hosted option like Tesseract.

What's the best free OCR tool?
Tesseract is the strongest free option if you're comfortable with some setup, since it runs entirely on your own machine. Google Vision and Mistral OCR both offer a limited free tier for testing before you need to pay.

When should I use an OCR API instead of a web tool?
Once you're processing documents regularly, automatically, or as part of a larger workflow, an API replaces manual uploads with a single function call and scales with your volume without extra manual work.

Is Tesseract still a good option in 2026?
Yes, for teams that prioritize cost and data privacy over top-tier accuracy on difficult documents. It's less accurate than AI-native APIs on handwriting or low-quality scans, but it's free, self-hosted, and actively maintained.

Looking for technical content like this for your company?

I write comparisons and tutorials for API and document-processing companies.
→ More about my work

5 Best Free AI Courses in 2026 (With Certificates)

Kevin Meneses González — Sat, 01 Aug 2026 11:22:26 +0000

Most people assume learning AI seriously means paying for a bootcamp or a $200 certification program.

That's not true anymore.

Open any search for "AI courses" and you'll land on the same problem every time: dozens of tabs, half of them paywalled, half of them outdated, and no clear sense of which one actually matches your level. You start an advanced course with zero foundations. You finish a beginner course you'd already outgrown. You bookmark five links and never open them again.

That's not a knowledge problem.

It's a filtering problem.

Most "best AI courses" roundups make it worse. They repeat the same generic Coursera or edX links, list them in no particular order, and never tell you whether a course assumes you can code or whether it teaches anything you couldn't already find in the docs for free.

The real problem isn't finding a course. It's finding the right one for where you actually are, in the right order.

That's what this list solves. Five free courses, all with certificates, ordered from complete beginner to advanced developer.

If you're:

starting from zero and just want to understand what AI actually is,
a developer wanting to build with LLMs and tools like Claude,
or already technical and looking to go deeper into Transformers and NLP,

there's a course below built for exactly that.

1. Anthropic Academy - Claude 101

Anthropic is the company behind Claude, one of the most capable AI models available today, with a rapidly growing set of tools around it.

Claude 101 is the foundational course inside Anthropic Academy. It covers what Claude actually is, how to start a conversation, and how to write better prompts to get more reliable results.

It also goes further than most beginner courses by introducing Projects, Skills, and MCP (Model Context Protocol), which is how Claude connects to external tools and data sources to extend what it can do.

The course includes a certificate you can add to LinkedIn or your resume.

→ Start Claude 101 on Anthropic Academy

Pros

Covers both fundamentals and practical prompt optimization
Introduces MCP, a concept most beginner courses skip entirely
Certificate included at no cost

Cons

Focused specifically on the Claude ecosystem, not model-agnostic

Best for: anyone starting from zero who wants a foundation built around a real, production-grade AI tool instead of abstract theory.

Anthropic Academy also offers a follow-up course on Claude Code, aimed at developers who want to use AI for programming tasks. Worth checking once you finish Claude 101.

2. AI For Everyone - Andrew Ng

If there's one instructor almost universally recommended for AI fundamentals, it's Andrew Ng.

AI For Everyone is a beginner-level course, roughly 7 hours long, that covers what AI actually is, the terminology you'll keep running into, and the practical differences between AI models. It also walks through small projects so the concepts don't stay purely theoretical.

Like the first course on this list, it's free and includes a certificate.

→ Start AI For Everyone on Coursera

Pros

Taught by one of the most recognized instructors in the field
Clear, jargon-light explanations of AI terminology
Includes practical mini-projects, not just lectures

Cons

Intentionally high-level. Not for anyone wanting technical depth

Best for: complete beginners who want a solid conceptual map before touching any code.

3. Hugging Face - NLP Course

Hugging Face functions as the GitHub of AI models. If you're building anything involving language models, you'll end up there eventually.

This course is more technical and assumes you already have some AI foundation. It covers Transformers, NLP fundamentals, tokenization, and how to fine-tune and optimize models so they work well with your own data.

→ Start the NLP Course on Hugging Face

Pros

Deep, hands-on coverage of Transformers and tokenization
Directly applicable to real model fine-tuning work
Free, with strong community support around it

Cons

Not beginner-friendly. Requires prior AI/ML context

Best for: developers ready to move from "using AI tools" to actually building and customizing models.

4. Google - Generative AI Learning Path

Google's ecosystem includes Gemini, one of the leading models alongside Claude and ChatGPT.

This learning path covers the fundamentals of generative AI, how Google's infrastructure supports these models, and how to build applications ranging from image generation to voice. It also explains what an LLM actually is and how to make use of the resources Google makes available to developers.

→ Start the Generative AI Learning Path on Google Skills

Pros

Covers multiple modalities: text, image, and voice generation
Backed by Google's own infrastructure and documentation
Multiple course tracks depending on your interest

Cons

Broader scope means less depth per topic compared to Hugging Face's course

Best for: developers who want to understand the infrastructure side of generative AI, not just the model layer.

5. ChatGPT - Building Agents and Workflows

The last course on this list focuses on something increasingly relevant in 2026: agents and workflow automation.

This free course, built around the ChatGPT ecosystem, takes about 90 minutes and covers how to build agents and automated workflows to handle repetitive tasks and improve your daily productivity.

→ Start Agents and Workflows on OpenAI Academy

Pros

Short and focused. Around 90 minutes total
Directly applicable to automating real tasks
Free, no certificate paywall

Cons

Shorter format means less depth than the other courses on this list

Best for: anyone who already understands AI basics and wants to start automating tasks with agents right away.

How to Choose Your Path

You don't need all five. Pick based on where you are:

Starting from zero? Anthropic Academy's Claude 101, then Andrew Ng's course.
Already technical, want to build models? Hugging Face's NLP course.
Interested in the infrastructure behind generative AI? Google's learning path.
Want to automate tasks right now? The ChatGPT agents course.

Want a personalized AI roadmap instead of a generic course list?
I offer 1:1 consulting sessions based on your specific goals and current AI setup.
→ Book a consultation

Key Takeaways

The best AI courses in 2026 are free and include certificates, no need to pay for a bootcamp to start.
Level matters more than course popularity. Match the course to where you actually are, not where you want to be.
MCP, agents, and workflow automation are now core topics, not optional extras, for anyone learning AI in 2026.

FAQs

❓ Are there really free AI courses with certificates in 2026?
✅ Yes. Anthropic Academy, Andrew Ng's AI For Everyone, and Google's Generative AI Learning Path all offer free certificates you can add to LinkedIn or your resume.

❓ What's the best AI course for complete beginners?
✅ Start with Anthropic Academy's Claude 101 or Andrew Ng's AI For Everyone. Both are designed for zero prior knowledge and take just a few hours to complete.

❓ Do I need to know how to code to take these courses?
✅ No. Courses 1, 2, 4, and 5 on this list require no coding background. Only Hugging Face's NLP course assumes prior technical experience.

Are you a software or API company that needs technical content, not marketing fluff?
I write SEO-optimized articles, tutorials, and video content that actually explain your product to developers.
→ Get in touch on LinkedIn

Want more AI and fintech content like this?
→ Explore more articles

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

How I Built a Portfolio Risk & Return Tracker with EODHD

Kevin Meneses González — Sat, 25 Jul 2026 10:33:40 +0000

Most retail investors track their portfolio in a spreadsheet.

Some upgrade to a free app that shows total value and daily change. That's it.

Neither tells you the numbers that actually matter: your annualized volatility, your Sharpe ratio, your beta against the market, your maximum drawdown, how correlated your positions really are with each other.

Institutional investors have had this for decades. Retail investors get a pie chart.

If you're:

managing your own portfolio across multiple brokers,
building a fintech side project,
or just tired of guessing how risky your holdings actually are,

this matters.

The spreadsheet problem

Excel is where most portfolios go to die.

You start with a clean sheet. One column per position, one row per transaction. It works — for about three months.

Then you add a new broker account. Then you start tracking dividends separately. Then a formula breaks because you inserted a row in the wrong place, and you don't notice until your total is off by 4%.

Spreadsheets don't calculate volatility, beta, or drawdown by default. You'd have to build those formulas yourself, pull historical prices manually, and keep them updated — forever, by hand.

Most people don't. So they end up managing a portfolio without knowing its actual risk profile.

The paid-tool problem

The other option is a paid portfolio tracker or a Bloomberg-style terminal.

These solve the calculation problem. They don't solve the trust problem.

Your position sizes, tickers, and entry prices sit on a third-party server.
You pay a monthly fee for metrics that are, mathematically, not complicated.
Many of these tools are optimized to upsell you into their brokerage or premium tier, not to give you a neutral view of your risk.

Sharpe ratio, beta, drawdown, correlation — these aren't proprietary black-box models. They're well-defined formulas. Paying $30/month to have someone else run them on your data, on their servers, is a trade-off a lot of people make without questioning it.

The real problem isn't a lack of financial data. It's a lack of a tool that computes real risk metrics, locally, without asking you to hand your portfolio to a third party.

Vault: a portfolio tracker that runs in your browser

I built Vault, an open source portfolio tracker with React 19 and Vite that uses the EODHD API to pull real market data and calculate six metrics that any serious investor should be tracking:

Returns — portfolio performance vs. S&P 500, indexed and per-position
Diversification — position weights and concentration (Herfindahl-Hirschman Index)
Risk — annualized volatility, Sharpe ratio, beta vs. market, 95% daily VaR
Drawdown — underwater curve and maximum historical drawdown
Correlations — Pearson correlation matrix between your holdings
Sector exposure — GICS sector breakdown from EODHD fundamentals

No backend. No account. No server storing your positions.

Everything runs in the browser, and your portfolio is saved in localStorage — on your machine, not on mine.

A quick note on EODHD

I've used EODHD across several projects before this one, mainly because of three things:

One API key covers historical prices, fundamentals, and search — no juggling three different providers
The free tier is generous enough to actually build and test a real project on it
Response format is consistent across endpoints, which cuts down on glue code

If you want to follow along or fork Vault, you'll need a key — get one free here.

How the calculations actually work

All the math lives in a single file: src/utils/finance.js. No external statistics libraries — every formula is implemented from scratch.

Time-weighted returns

Each day is weighted by the previous day's closing value. This matters more than it sounds: without it, adding a new position mid-month distorts your daily portfolio return.

Volatility and Sharpe ratio

Standard deviation of daily returns, annualized with √252, then converted to a Sharpe ratio against a configurable risk-free rate.

Here's the core of it, simplified to Python for clarity:

import numpy as np

def annualized_volatility(daily_returns):
    return np.std(daily_returns) * np.sqrt(252)

def sharpe_ratio(daily_returns, risk_free_rate=0.02):
    excess_returns = np.array(daily_returns) - (risk_free_rate / 252)
    return (np.mean(excess_returns) / np.std(daily_returns)) * np.sqrt(252)

Beta

Covariance of portfolio returns against the S&P 500 (GSPC.INDX on EODHD), divided by the benchmark's variance.

Drawdown

Percentage drop from the running peak of a growth-indexed curve (base 100). This is the number that tells you what it would have actually felt like to hold this portfolio through its worst stretch.

Correlation matrix

Pairwise Pearson coefficient between assets, aligned by date. This is the metric most retail portfolios get wrong without knowing it — five stocks can feel diversified and still move together 90% of the time.

Concentration (HHI)

Herfindahl-Hirschman Index applied to position weights. One number that tells you how concentrated you actually are, beyond "I have 12 positions so I'm diversified."

From here, the same building blocks extend into:

automated risk alerts
portfolio rebalancing scripts
backtesting engines

What it looks like in practice

You add a position, EODHD's Search + EOD endpoints autocomplete the ticker and the closing price on your purchase date.

From there, Vault renders your returns curve against the S&P 500, your correlation heatmap, and your sector exposure pulled straight from fundamentals data.

No manual formula-building. No re-entering prices when a position updates.

Key takeaways

Portfolio risk metrics (Sharpe, beta, drawdown, correlation) aren't proprietary — they're standard formulas most tools just gatekeep behind a paywall
Running them client-side means your positions never leave your browser
EODHD's Search, EOD, and Fundamentals endpoints cover everything needed to build this without stitching together multiple data providers

Try it yourself

git clone https://github.com/Kevinelectronics/portafoliotracker.git
cd portafoliotracker
npm install

Add your EODHD key to .env, run npm run dev, and add your first position.

Get your free EODHD API key
Vault runs entirely on EODHD's Search, EOD, and Fundamentals endpoints — no backend, no paywall on the metrics.
→ Get your EODHD API key

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.

Need technical content like this for your product?
→ kevinmeneses.com

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

How to Build a RAG Pipeline from PDFs Using Python

Kevin Meneses González — Fri, 24 Jul 2026 14:07:41 +0000

How to Build a RAG Pipeline from PDFs Using Python

Most RAG pipelines don't fail at retrieval. They don't fail at the model either.

They fail at ingestion — the moment a messy PDF gets dumped straight into a text splitter and comes out the other side as noise.

TL;DR

Feeding raw PDF text into a chunker is where most RAG pipelines quietly break: tables split mid-row, headings disappear, chunks lose their context.
The fix isn't a better chunking algorithm. It's converting the PDF into clean, structured Markdown before you chunk anything.
Nutrient's Python SDK (nutrient_dws) turns a PDF into Markdown in one call, preserving headings, lists, and tables — so your chunker can split on structure instead of guessing at character counts.
Below: a full Python walkthrough — PDF → Markdown → heading-aware chunks → ready for embeddings.

What actually breaks in a naive RAG pipeline

The typical first version of a RAG pipeline looks like this: extract raw text with a generic PDF library, split it every N characters, embed each chunk, done.

It works on a clean text file. It falls apart on a real PDF:

A table gets flattened into a single line of numbers with no column boundaries — the chunk that gets retrieved is unreadable
A heading ends up alone at the bottom of one chunk, with its content starting the next one — retrieval finds the content but the model never sees what section it belongs to
Multi-column layouts get merged out of order, so a chunk contains half of one paragraph and half of an unrelated one

None of this shows up in a demo with three test PDFs. It shows up in production, on document #47, and it looks like a "retrieval quality" problem when it's actually an ingestion problem.

The fix: structure before chunking

A RAG pipeline that holds up in production treats ingestion as its own stage — not a one-liner before the real work starts.

The order that actually works is: extract structure, then chunk on structure, then embed. Chunk boundaries should follow headings and paragraph breaks the document already has, not an arbitrary character count that cuts through them.

Architecture

PDF
 │
 ▼
Python SDK (nutrient_dws) — mode="text", output_format="markdown"
 │
 ▼
Clean Markdown (headings, lists, tables preserved)
 │
 ▼
Heading-aware chunker (splits on headings, then paragraph breaks)
 │
 ▼
Embedding model
 │
 ▼
Vector store

The chunker is the piece most tutorials skip past. It's also the piece that determines whether your retrieved chunks make sense to the model or arrive as disconnected fragments.

Implementation: PDF to Markdown with the Python SDK

Nutrient's official Python client, nutrient_dws, wraps document parsing in a simple async call. For born-digital PDFs, mode="text" is the fastest and cheapest path — 1 credit per page:

import asyncio
from nutrient_dws import NutrientClient

client = NutrientClient(
    api_key="your_processor_key",
    extract_api_key="your_extract_key",
)


async def pdf_to_markdown(path: str) -> str:
    response = await client.parse(path, mode="text", output_format="markdown")
    return response["output"]["markdown"]

That's the entire extraction step. The output preserves headings, lists, and tables as real Markdown syntax — not a flat text dump:

# Employee Handbook

## Time Off Policy

Full-time employees accrue 1.5 days of PTO per month...

| Tenure | Annual PTO |
|--------|-----------|
| 0–2 years | 15 days |
| 3–5 years | 20 days |

If your source documents are scanned rather than born-digital, switch to mode="structure" so OCR runs before the Markdown conversion.

Implementation: chunking on structure, not character count

Once you have Markdown, split on headings first — so no chunk ever straddles a section boundary — then fall back to paragraph breaks for sections that are still too long:

import re


def chunk_markdown(markdown: str, max_chars: int = 1500) -> list[str]:
    # Split on Markdown headings so a chunk never crosses a section boundary
    sections = re.split(r"(?=^#{1,3} )", markdown, flags=re.MULTILINE)

    chunks = []
    for section in sections:
        if not section.strip():
            continue
        if len(section) <= max_chars:
            chunks.append(section.strip())
            continue
        # Long section: split further on paragraph breaks
        paragraphs = section.split("\n\n")
        buffer = ""
        for para in paragraphs:
            if len(buffer) + len(para) > max_chars and buffer:
                chunks.append(buffer.strip())
                buffer = ""
            buffer += para + "\n\n"
        if buffer.strip():
            chunks.append(buffer.strip())
    return chunks

Putting both pieces together:

async def main():
    markdown = await pdf_to_markdown("company_handbook.pdf")
    chunks = chunk_markdown(markdown)
    print(f"Generated {len(chunks)} chunks")
    # Next: embed each chunk and upsert into your vector store of choice


if __name__ == "__main__":
    asyncio.run(main())

Every chunk that comes out of this now maps to a real section of the document — a heading and the content underneath it, or a table with its rows intact — instead of an arbitrary character window.

When you need more than Markdown

Markdown chunking covers most RAG ingestion. But some documents need the model to answer questions that depend on exact table structure — "what was the Q3 number in the third row" — where flattening a table into Markdown text still loses precision.

For those cases, request spatial JSON output instead of Markdown from the same parse() call, or use mode="understand" for documents with complex layouts, key-value regions, or handwriting. Spatial output gives you row/column-indexed table cells with bounding boxes and confidence scores — useful when you need to validate or cite the exact source location, not just retrieve a paragraph.

Pros and cons

Pros

One SDK call replaces a generic PDF parser plus custom table/heading recovery logic
Markdown output is chunker-friendly out of the box — headings and tables survive
Switching to mode="structure" handles scanned PDFs without a separate OCR step
Same client can return spatial JSON for documents needing exact structure, not just clean text

Cons

Markdown and spatial JSON are separate outputs from the same request — decide upfront which one a document needs
mode="text" assumes a born-digital PDF; scanned documents need mode="structure", which costs more and runs slower
The chunker above is heading-aware but simple — documents with deeply nested headings may need a more sophisticated splitter

Best for: teams building RAG pipelines from real-world PDFs — internal knowledge bases, policy documents, technical manuals — where retrieval quality depends on chunks that actually correspond to a coherent section of the source document.

Key takeaways

Ingestion, not retrieval, is where most RAG pipelines from PDFs actually break.
Converting to structured Markdown before chunking means your splitter works with real section boundaries instead of guessing at character counts.
nutrient_dws's parse() call handles this in one step for born-digital PDFs, with mode="structure" as the fallback for scans.

FAQs

❓ Do I need a separate OCR step before this pipeline?
✅ No. Switching mode="text" to mode="structure" runs OCR as part of the same parse() call for scanned or image-based PDFs — no separate pipeline to maintain.

❓ Why not just chunk by a fixed character count?
✅ Fixed-length chunking ignores document structure — a chunk can start mid-table or split a heading from its content, which hurts both retrieval relevance and what the model can make sense of once a chunk is retrieved.

❓ Can I get both Markdown and spatial JSON from one request?
✅ No — they're separate output formats on the same parse() call. If a document needs both (Markdown for RAG, spatial JSON for exact table validation), send two requests.

❓ What if my documents have deeply nested headings or unusual structure?
✅ The chunker in this walkthrough handles up to three heading levels (#, ##, ###). For more complex documents, you can extend the regex or add a maximum nesting depth before falling back to paragraph-level splitting.

❓ Is mode="text" accurate enough for documents with some tables?
✅ For simple tables in born-digital PDFs, yes — they convert to Markdown table syntax correctly. For scanned tables or documents where table accuracy is critical, use mode="structure" or mode="understand" instead.

Nutrient Data Extraction API
Turn PDFs into clean Markdown or spatial JSON — one Python SDK, born-digital or scanned.
→ Get started free

Kevin Meneses González
Technical content for fintech and API companies — articles, tutorials, and video.

OCR vs AI Document Extraction: What's the Difference

Kevin Meneses González — Wed, 22 Jul 2026 10:32:27 +0000

"Which OCR should I use?" is usually the wrong question.

If you're:

automating invoice or form processing,
building a RAG pipeline from PDFs,
or setting up a compliance workflow that needs traceable data,

the question that actually matters is: do you need text, or do you need structure?

The goal isn't just to make a document readable. The goal is to make document data usable, reviewable, and ready for downstream systems.

TL;DR

OCR answers "what does this text say?" — it converts pixels into characters.

AI document extraction answers "what is this content, where is it on the page, and how does it relate to the rest of the document?" — it preserves structure like tables, fields, reading order, and source context.

Nutrient Data Extraction API exposes this as four processing modes — Text, Structure, Understand, and Agentic — so you can match extraction depth to document complexity.

Use Parse when you need full document structure as Markdown or spatial JSON. Use Extract when you need specific schema-defined fields returned as structured JSON with source context for review.

Below: the same document requested in two output formats, so you can see exactly where plain text extraction stops and structure begins.

Why "OCR" became the wrong catch-all term

Most people use "OCR" to mean "get text out of an image." That's technically correct and practically misleading.

Plain OCR usually gives you recognized text, sometimes with word or line positions. But it does not reliably preserve higher-level structure like tables, field relationships, heading hierarchy, or reading order across complex layouts. Some OCR engines return positions or basic layout hints, but that's not the same as understanding how a page is organized.

Then teams plug that output into a downstream system expecting structure — and discover the table became "Invoice #2024-0892\nItem Amount\nWidget A $45.00", with no indication of which value belongs to which column.

That's not an OCR bug. It's OCR doing exactly what it was built to do.

The real difference: reading vs understanding

OCR reads. It converts pixels to characters, in roughly left-to-right, top-to-bottom order, and stops there.

Document understanding — the job behind AI-powered document extraction — analyzes layout. It detects tables and preserves rows and columns. It recognizes reading order across multi-column pages. It classifies elements (paragraph, heading, table, key-value region) instead of just returning a wall of text.

The distinction that matters in practice: plain text extraction gives you the words. Structured extraction gives you the words with layout, relationships, and context

Four modes, one spectrum

Nutrient Data Extraction API makes this spectrum concrete with four processing modes, all reachable through the same API:

Capability	Text	Structure	Understand	Agentic
Text extraction	Yes	Yes	Yes	Yes
Table structure	No	Yes	Yes	Yes
Key-value regions	No	Yes	Yes	Yes
Handwriting	No	Limited	Yes	Yes
Formulas	No	No	Yes, as LaTeX	Yes, as LaTeX
Reading order	Basic	Layout-aware	Layout-aware	Layout-aware, deeper reasoning
Best fit for	Fast Markdown/text extraction for born-digital documents	Spatial JSON and OCR-backed layout for scans and image-based documents	Complex layouts, tables, handwriting, formulas, and richer structure	The most complex documents that need deeper visual reasoning and recovery
Relative cost/speed	Fastest, cheapest	Moderate	Higher	Highest, slowest

Text mode — Fast text extraction for born-digital documents.

Structure mode — OCR-backed structure extraction for scans and image-based documents.

Understand mode — ICR for complex layouts, handwriting, formulas, OCR correction, and richer document structure.

Agentic mode — VLM-enhanced ICR for deeper visual reasoning, semantic understanding, and recovery.

Under the hood, components like OCR and ICR (intelligent character recognition) do the character-level work, but the mode you choose is what actually changes what comes back.

Studio-first, API-next

Before deciding which mode fits a document, Data Extraction API Studio lets you upload a file, run it through Parse, compare modes side by side, and inspect the Markdown or JSON output directly in your browser — 5,000 free credits, no credit card required. It's the fastest way to see the difference on your own documents before writing any integration code.

→ Get started free

Parse vs. Extract, and Markdown vs. JSON

There are two separate choices that shape what comes back from the API, and it's worth naming both before writing any code: what job you want the API to perform, and what output format your workflow needs.

Use Parse when you want the full document structure. The Markdown response is clean, readable content for AI, RAG, search, and document Q&A. It is easier to work with than raw OCR text, but it is not the best format when you need layout-aware elements, coordinates, confidence, and table cell relationships.

Use Extract when you need specific schema-defined fields — invoice number, vendor, total, line items, contract dates, form values — returned as structured JSON with source context for review. Studio's schema generator can scaffold a starting schema from a sample document, which you can review and refine before running extraction.

The processing mode (Text/Structure/Understand/Agentic) determines how deeply the document is analyzed. The output format determines how the result is handed back to you.

Implementation: the same document, two output formats

Here's the same intake form requested in two output formats — Markdown for clean, readable content, and JSON for layout-aware structure — using the REST API:

curl -X POST https://api.nutrient.io/extraction/parse \
  -H "Authorization: Bearer $NUTRIENT_API_KEY" \
  -F "file=@intake_form.pdf" \
  -F 'instructions={"output":{"format":"markdown"}}'

curl -X POST https://api.nutrient.io/extraction/parse \
  -H "Authorization: Bearer $NUTRIENT_API_KEY" \
  -F "file=@intake_form.pdf" \
  -F 'instructions={"output":{"format":"json"}}'

Same file, same endpoint. The processing mode is set as a separate request parameter alongside the output format — check the API documentation for the current field name and accepted values, or set it directly in Studio and copy the generated request.

The Markdown response is a clean, flat rendering of the content — accurate, but with table rows collapsed into plain text. A simplified spatial JSON response might look like this:

{
  "elements": [
    {
      "type": "table",
      "boundingBox": { "x": 45, "y": 200, "width": 680, "height": 340 },
      "readingOrder": 1,
      "children": [
        { "type": "tableCell", "text": "Item", "row": 0, "column": 0 },
        { "type": "tableCell", "text": "Amount", "row": 0, "column": 1 }
      ]
    }
  ]
}

That nesting is the entire difference. Plain text extraction never produces it — not because it's less accurate, but because table structure isn't something character recognition alone is designed to detect.

Scaling up: processing 100 invoices

A single curl call is enough to see the difference between output formats. It's not enough to run a real batch. Here's a simple Python script that walks a folder of invoices, sends each one through the API, and saves the results — the kind of script you'd actually point at 100 files:

"""
Batch-process a folder of invoices through the Nutrient Data Extraction API.

Usage:
    python batch_extract.py ./invoices --format json --out ./results
"""

import argparse
import json
import time
from pathlib import Path
# Note:
# The response field names below (for example "output" and
# "usage.data_extraction_credits") are illustrative.
# Verify the current response schema in the official API
# documentation before using this script in production.

import requests

API_KEY = "your_api_key"
URL = "https://api.nutrient.io/extraction/parse"


def extract_one(pdf_path: Path, output_format: str) -> dict:
    with open(pdf_path, "rb") as f:
        response = requests.post(
            URL,
            headers={"Authorization": f"Bearer {API_KEY}"},
            files={"file": f},
            data={"instructions": f'{{"output":{{"format":"{output_format}"}}}}'},
            timeout=60,
        )
    response.raise_for_status()
    return response.json()


def main():
    parser = argparse.ArgumentParser(description="Batch extract invoices with Nutrient")
    parser.add_argument("folder", help="Folder containing invoice PDFs")
    parser.add_argument("--format", choices=["markdown", "json"], default="json")
    parser.add_argument("--out", default="./results", help="Folder to write results to")
    args = parser.parse_args()

    input_dir = Path(args.folder)
    output_dir = Path(args.out)
    output_dir.mkdir(parents=True, exist_ok=True)

    pdf_files = sorted(input_dir.glob("*.pdf"))
    print(f"Found {len(pdf_files)} invoices")

    failed = []
    total_credits = 0

    for i, pdf_path in enumerate(pdf_files, start=1):
        print(f"[{i}/{len(pdf_files)}] {pdf_path.name}")
        try:
            result = extract_one(pdf_path, args.format)
        except requests.HTTPError as e:
            print(f"  failed: {e}")
            failed.append(pdf_path.name)
            continue

        # Note: field names below (output, usage.data_extraction_credits) should be
        # confirmed against the current API reference before running this in production.
        out_path = output_dir / f"{pdf_path.stem}.{('json' if args.format == 'json' else 'md')}"
        content = result["output"].get(args.format, result["output"])
        if isinstance(content, dict):
            content = json.dumps(content, indent=2)
        out_path.write_text(content, encoding="utf-8")

        credits = result.get("usage", {}).get("data_extraction_credits", {})
        total_credits += credits.get("cost", 0)

        # Simple pacing to stay under rate limits on large batches
        time.sleep(0.2)

    print(f"\nDone. {len(pdf_files) - len(failed)} succeeded, {len(failed)} failed.")
    print(f"Total credits used: {total_credits}")
    if failed:
        print("Failed files:", ", ".join(failed))


if __name__ == "__main__":
    main()

Run it: python batch_extract.py ./invoices --format json --out ./results.

A few things worth calling out for a batch like this:

Failures are tracked, not fatal. One malformed PDF in a folder of 100 shouldn't kill the run — the script logs it and keeps going, then prints the failed filenames at the end so you can retry just those.
Credit usage is summed across the batch, so you know the actual cost of processing 100 invoices before you scale to 1,000.
The time.sleep(0.2) is a simple pacing guard, not a rate-limit implementation — for larger batches or production use, check the API docs for current rate limits and consider proper backoff instead of a fixed delay.
Structure or Understand mode is usually the better starting point for real invoices, especially when you need tables, line items, and totals

When each one is the wrong tool

Text mode is the wrong tool when: you need to reconstruct a table, route a form field to the correct database column, or trust that "Total" and "$4,250" are actually linked. It will hand you the right characters in the wrong shape.

Understand or Agentic mode is the wrong tool when: you're indexing millions of simple, clean digital pages for keyword search and don't need layout at all. Running the deepest mode on documents that Text mode would handle just as well is the most common way teams overpay for extraction they don't need.

Match the mode to the job — not the other way around. If you need specific fields rather than the whole document, Extract with a schema (generated from a sample document via Studio's schema generator) is usually a better fit than parsing the full page and post-processing it yourself.

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.

Key takeaways

Plain OCR converts pixels to characters. Plain text extraction gets text out, but it was never meant to understand layout.
Structure, Understand, and Agentic modes classify elements, preserve table structure, and determine reading order — a different job, not a better version of the same job.
Picking the right mode per document (not defaulting to the most powerful one) is what keeps extraction both accurate and cost-efficient.

FAQs

❓ Is AI document extraction just "OCR with AI added"?
✅ Not exactly. OCR is the character-recognition layer. AI document extraction uses OCR or other recognition methods as part of a broader pipeline that also analyzes layout, detects tables, identifies fields, preserves reading order, and returns structured output.

❓ Do I need to run OCR separately before using Structure or Understand mode?
✅ No — both modes already include character recognition as part of the pipeline. You don't run OCR first and then request structure on top; you pick the mode that matches what the document needs.

❓ Can Text mode handle scanned tables if I clean up the output myself?
✅ You can write custom logic to reconstruct a table from flat text, but it breaks the moment a vendor changes their layout. Structure mode is designed to reduce this brittleness by returning layout-aware elements, table structure, coordinates, and page context.

❓ Which mode should I default to if I'm not sure?
✅ Start with Structure mode for scanned or image-based documents. Move up to Understand or Agentic when tables, columns, handwriting, or complex layouts need deeper analysis

❓ Does a more advanced mode always mean better results?
✅ Not for every document. Understand and Agentic modes cost more and run slower than Structure — worth it for genuinely complex layouts, unnecessary overhead for a clean, well-structured scan.

Nutrient Data Extraction API
Turn PDFs, scans, images, and Office files into structured JSON or clean Markdown — with the right mode for every document.
→ Get started free

From Messy PDFs to Structured JSON: An LLM-Ready Workflow

Kevin Meneses González — Thu, 16 Jul 2026 09:33:16 +0000

Most AI pipelines don't fail because of the model.

They fail because of the input.

If you're:

building RAG pipelines,
automating invoice or contract intake,
or feeding documents into an LLM for Q&A,

the PDF is usually the weakest link in the chain.

TL;DR

A PDF is a layout format, not a data format. Generic text extraction often loses reading order, table structure, and source context.
Nutrient Data Extraction API turns PDFs, scans, images, and Office files into structured output: structured JSON for schema-defined extraction and downstream systems, or Markdown for AI/search workflows.
Use Studio to test documents first, compare processing modes, generate schemas, and inspect output before integrating with the API.
The API supports four processing modes — Text, Structure, Understand, and Agentic — so teams can balance speed, cost, and extraction quality based on document complexity.

The PDF was never built for this

A PDF remembers how a page looks. It doesn't remember what the content is.

That distinction breaks most naive extraction attempts:

Text is stored in fragments, often out of reading order
Tables are just aligned text — there's no actual "table" object
Scanned pages have no text layer at all
Two-column layouts get merged into a single unreadable stream

Developers usually discover this too late — after a regex-based parser works fine on three test invoices and then falls apart on the fourth, because the vendor used a different template.

Why text extraction alone isn't enough

Getting text out of a PDF is easy. Getting text out with the relationships preserved — which value belongs to which row, which heading owns which paragraph, which number came from which page — is the actual job.

An LLM does not just need more text. It needs structured content that preserves context, order, and source grounding.

Nutrient Data Extraction API: Studio-first, API-next

Nutrient Data Extraction API processes PDFs, scans, images, and Office files, and returns either structured JSON or clean Markdown, with source context such as confidence scores, page references, and coordinates.

Before wiring extraction into an application, you can test documents in Data Extraction API Studio. Upload a file, choose Parse or Extract, compare processing modes, inspect Markdown or JSON output, and review source context before moving to the API — 5,000 free credits, no credit card required.

Parse vs. Extract

The API gives you two request paths, and picking the right one matters:

Parse returns the full document content as clean Markdown or structured JSON blocks — use it when you need the whole document, structured.
Extract pulls specific fields you define in a schema — such as invoice number, total amount, or vendor name — use it when you know exactly which fields you need out of a document type.

Most RAG and search use cases run through Parse. Invoice, form, and structured-record workflows usually reach for Extract once the schema is defined.

Markdown vs. spatial JSON

Parse and Extract are about which request you send. Markdown and spatial JSON are about what format the content comes back in — and that choice is independent of Parse vs. Extract; both output formats are available either way.

Markdown is clean, structured content — headings, lists, and tables rendered as Markdown syntax (including real <table> markup for tables). It's positioned as the go-to format for AI and search workflows: RAG ingestion, document Q&A, knowledge base indexing, content migration. It reads like a well-formatted document, not a data structure.

Spatial JSON is the layout-aware format — a typed list of elements, each with its type, its role (heading, body text, footer, and so on), its bounding box, its reading order, and a confidence score. It's the stronger choice when you need element types, bounds, coordinates, and confidence, or when a value has to be traceable back to an exact position on the page — table cell validation, form field mapping, audit trails.

A rule of thumb: if the next step is "feed this to an LLM or a search index," reach for Markdown. If the next step is "validate this value, map it to a database column, or highlight it on the source page," reach for spatial JSON.

They're separate output formats on the same Parse request — check the API docs for the current recommended pattern if a workflow genuinely needs both from one document.

Processing modes: matching depth to the document

Instead of a single one-size-fits-all pass, the API gives you four processing modes:

Mode	When to use it
Text	Born-digital documents where speed and cost matter
Structure	Scans and image-based documents that need OCR and layout
Understand	Complex layouts, tables, handwriting, forms, and higher-quality structure
Agentic	Visually complex or ambiguous documents where deeper reasoning is worth the extra cost — deeper visual reasoning and recovery for documents that need more advanced analysis

You pick the mode per document. A clean digital invoice doesn't need the same processing budget as a scanned, handwritten form.

Schema generation for field extraction

For Extract workflows, you don't have to write a schema from scratch. Schema generator can create a starting schema from a sample document — you then review and refine the fields, types, and instructions before running extraction through the API.

This matters in practice: most teams don't know the exact field list a document type needs until they've looked at a handful of real samples. Starting from a generated schema and refining it is faster and more accurate than guessing upfront.

API example: parsing a document

Here's a minimal Parse request that converts a PDF to Markdown:

curl -X POST https://api.nutrient.io/extraction/parse \
  -H "Authorization: Bearer $NUTRIENT_API_KEY" \
  -F "file=@document.pdf" \
  -F 'instructions={"output":{"format":"markdown"}}'

Swap "format":"markdown" for "format":"json" when you need structured elements with coordinates and confidence instead of clean Markdown — for example, when you need to trace a value back to its exact position on the page, or preserve table cell structure precisely.

A reusable Python script

The curl one-liner is fine for a quick test. For anything you'll run more than once, here's a small Python CLI wrapper around the same endpoint — it takes a PDF path, an output format, and an optional output file:

"""
Extract structured content from a PDF using the Nutrient extraction API.

Setup:
    pip install -r requirements.txt
    Copy .env.example to .env and add your Nutrient API key.

Usage:
    python extract_pdf.py path/to/file.pdf
    python extract_pdf.py path/to/file.pdf --format json
    python extract_pdf.py path/to/file.pdf --output result.md
"""

import argparse
import os
import sys

import requests
from dotenv import load_dotenv

load_dotenv()
API_KEY = os.getenv("NUTRIENT_API_KEY")
URL = "https://api.nutrient.io/extraction/parse"


def extract(pdf_path: str, output_format: str = "markdown") -> dict:
    with open(pdf_path, "rb") as f:
        r = requests.post(
            URL,
            headers={"Authorization": f"Bearer {API_KEY}"},
            files={"file": f},
            data={"instructions": f'{{"output":{{"format":"{output_format}"}}}}'},
            timeout=60,
        )
    r.raise_for_status()
    return r.json()


def main():
    parser = argparse.ArgumentParser(description="Extract content from a PDF via Nutrient")
    parser.add_argument("pdf", help="Path to the PDF file")
    parser.add_argument("--format", choices=["markdown", "json", "text"], default="markdown")
    parser.add_argument("--output", help="Write the extracted content to this file instead of stdout")
    args = parser.parse_args()

    if not API_KEY:
        sys.exit(
            "NUTRIENT_API_KEY not found. Create a .env file next to this script "
            "with the line: NUTRIENT_API_KEY=your_api_key"
        )

    if not os.path.isfile(args.pdf):
        sys.exit(f"File not found: {args.pdf}")

    result = extract(args.pdf, args.format)
    content = result["output"].get(args.format, result["output"])
    if isinstance(content, dict):
        import json
        content = json.dumps(content, indent=2)

    if args.output:
        with open(args.output, "w", encoding="utf-8") as f:
            f.write(content)
        print(f"Saved to {args.output}")
    else:
        print(content)

    credits = result.get("usage", {}).get("data_extraction_credits", {})
    if credits:
        print(f"\n[credits used: {credits.get('cost')}, remaining: {credits.get('remainingCredits')}]", file=sys.stderr)


if __name__ == "__main__":
    main()

Drop this next to a .env file with NUTRIENT_API_KEY=your_api_key, and you have a script you can point at any PDF: python extract_pdf.py invoice.pdf --format json --output invoice.json. It's the same request the curl example makes — just wrapped in something you'll actually reuse.

For schema-defined Extract requests, the exact request shape depends on your schema — check the official API documentation for the current Extract endpoint and payload format, or generate a starting request directly from Studio once your schema is ready.

A JSON response from Parse looks like this — element types, positions, and reading order, not a flat text dump:

{
  "elements": [
    {
      "type": "paragraph",
      "text": "Invoice #2024-0892",
      "boundingBox": { "x": 45, "y": 120, "width": 310, "height": 28 },
      "readingOrder": 0
    },
    {
      "type": "table",
      "boundingBox": { "x": 45, "y": 200, "width": 680, "height": 340 },
      "readingOrder": 1,
      "children": [
        { "type": "tableCell", "text": "Item", "row": 0, "column": 0 },
        { "type": "tableCell", "text": "Amount", "row": 0, "column": 1 }
      ]
    }
  ]
}

Compare that to plain OCR output: "Invoice #2024-0892\nItem Amount\nWidget A $45.00" — with no indication of which value belongs to which column.

What a real response actually looks like

The example above is simplified to make the shape easy to read. Here's what Parse actually returns for a real invoice — anonymized, but otherwise untouched — first as Markdown, then as structured JSON.

Markdown output:

## Invoice

INV-2026-0001 Invoice number

July 3, 2026 Date of issue

## Medium

123 Main Street 94105 San Francisco California USA +1 555 010 2938

Date due July 17, 2026

## $175.00 USD due July 17, 2026

## Pay online

<table>
 <tr>
  <td>Description</td>
  <td></td>
  <td>Unit price</td>
  <td>Amount</td>
 </tr>
 <tr>
  <td>Content Marketing</td>
  <td>1</td>
  <td>$175.00</td>
  <td>$175.00</td>
 </tr>
 <tr>
  <td></td>
  <td>Subtotal</td>
  <td></td>
  <td>$175.00</td>
 </tr>
 <tr>
  <td></td>
  <td>Total</td>
  <td></td>
  <td>$175.00</td>
 </tr>
 <tr>
  <td></td>
  <td>Amount due</td>
  <td></td>
  <td>$175.00 USD</td>
 </tr>
</table>

## Medium

Bill to

Jamie Chen jamie.chen@example.com

Notice the table survives as real HTML <table> markup embedded in the Markdown — not flattened into a line of numbers. That's what makes Markdown output usable for RAG chunking without losing the row/column relationships.

JSON output (trimmed — the real response includes every element, and the table's cell array is shortened here for readability):

{
  "elements": [
    {
      "id": "ad35142f-5426-4995-94e3-56682a3a8c7c",
      "type": "paragraph",
      "role": "SectionHeader",
      "text": "Invoice",
      "confidence": 0.939276,
      "readingOrder": 0,
      "bounds": { "x": 84.03, "y": 92.88, "width": 170.97, "height": 42.12 },
      "page": { "pageNumber": 1, "width": 1700, "height": 2200 }
    },
    {
      "id": "a0d1192d-3d59-4a4b-b10f-16df2233dbbb",
      "type": "paragraph",
      "role": "Text",
      "text": "INV-2026-0001 Invoice number",
      "confidence": 0.904187,
      "readingOrder": 2,
      "bounds": { "x": 82.81, "y": 195.59, "width": 416.19, "height": 23.41 },
      "page": { "pageNumber": 1, "width": 1700, "height": 2200 }
    },
    {
      "id": "7184b67c-468d-42d6-9e00-f0dd10a2a4c3",
      "type": "paragraph",
      "role": "Text",
      "text": "123 Main Street\n94105 San Francisco\nCalifornia\nUSA\n+1 555 010 2938",
      "confidence": 0.680442,
      "readingOrder": 6,
      "bounds": { "x": 82.46, "y": 394.16, "width": 530.54, "height": 174.84 },
      "page": { "pageNumber": 1, "width": 1700, "height": 2200 }
    },
    {
      "id": "8532e005-9b64-4a04-9745-f1a963a27f4d",
      "type": "table",
      "readingOrder": 13,
      "confidence": 0.928583,
      "rowCount": 5,
      "columnCount": 4,
      "bounds": { "x": 80.54, "y": 825.07, "width": 1537.94, "height": 246.88 },
      "page": { "pageNumber": 1, "width": 1700, "height": 2200 },
      "cells": [
        { "row": 0, "column": 0, "text": "Description", "confidence": 1 },
        { "row": 0, "column": 2, "text": "Unit price", "confidence": 1 },
        { "row": 0, "column": 3, "text": "Amount", "confidence": 1 },
        { "row": 1, "column": 0, "text": "Content Marketing", "confidence": 1 },
        { "row": 1, "column": 3, "text": "$175.00", "confidence": 1 },
        { "row": 4, "column": 1, "text": "Amount due", "confidence": 1 },
        { "row": 4, "column": 3, "text": "$175.00 USD", "confidence": 1 }
      ]
    },
    {
      "id": "c38ff641-a643-4ad5-b9e2-4c370fc6a0b3",
      "type": "paragraph",
      "role": "Text",
      "text": "Jamie Chen\njamie.chen@example.com",
      "confidence": 0.686578,
      "readingOrder": 16,
      "bounds": { "x": 695.90, "y": 394.81, "width": 279.40, "height": 65.19 },
      "page": { "pageNumber": 1, "width": 1700, "height": 2200 }
    }
  ],
  "languageDetection": {
    "pages": [
      { "pageNumber": 1, "languages": ["eng"], "textDirection": "lrtb" }
    ]
  }
}

Two things worth pointing out here that don't show up in a toy example:

role classifies elements, not just types — SectionHeader, Text, and Footer all come back as paragraph type, but role tells you which one is a heading versus body text versus a page footer. That's the field to key off if you're deciding what belongs in a RAG chunk versus what to drop.
Confidence varies by element, and it's not always near 1.0 — the seller address block above scored 0.68, noticeably lower than the clean, high-contrast text elements around it. That's exactly the kind of value a validation threshold should catch before it moves downstream, not something to assume is correct because the rest of the document extracted cleanly.

The architecture: where extraction sits in the pipeline

It helps to see this as a layer, not a single API call. A production document pipeline usually looks like this:

Document intake (upload / email / scan / hosted URL)
        │
        ▼
Mode selection (Text / Structure / Understand / Agentic)
        │
        ▼
Nutrient Data Extraction API — Parse or Extract
   → structured JSON (elements, coordinates, confidence, reading order)
   → or Markdown (clean, LLM-ready content)
        │
        ▼
Validation layer
   → flag elements below a confidence threshold
   → route flagged elements to human review
        │
        ▼
Downstream systems
   → database / ERP (structured JSON)
   → RAG index / vector store (Markdown)
   → review queue (flagged elements + bounding boxes)

The part teams usually skip is the validation layer. Extraction without a confidence check just moves the trust problem one step downstream — instead of a human misreading a PDF, you get an LLM confidently building on top of a weak extraction. Coordinates and confidence scores make that validation step practical: you set a threshold (say, anything under 85% confidence), route those specific elements to a review queue, and let everything else flow through automatically.

Mode selection also isn't a one-time decision — it's a per-document routing rule. A born-digital invoice from your billing system doesn't need the same processing depth as a photographed, handwritten delivery note. Sending everything through the most expensive mode by default is the most common way teams overpay for extraction.

Pros and cons

Pros

Source context — confidence scores, page references, and coordinates — comes back alongside the extracted content, not just plain text
Four processing modes mean you're not paying for AI-heavy extraction on documents that don't need it
Same API handles PDFs, scans, images, and Office files — no separate OCR pipeline to maintain
Studio lets you test Parse and Extract, compare modes, and generate a schema before writing any integration code

Cons

Files are not persistently stored after processing, which is good for compliance but means you handle retention or audit storage yourself if you need it

Best for: teams building document-heavy pipelines — RAG ingestion, invoice/contract automation, compliance workflows — where "we got some text out" isn't good enough and you need to trace values back to their source.

Practical use cases

1. Invoice and statement processing
Route invoices through Structure or Understand mode via Extract with a schema for line items and totals, and flag any amount under your confidence threshold for a human to check before it posts to your accounting system.

2. Contract review pipelines
Use Parse to extract clause-level text with reading order preserved, so a downstream LLM step (clause classification, obligation extraction) works with clauses in the order they actually appear in the contract — not reshuffled by a naive text dump.

3. RAG knowledge base ingestion
Use Markdown output from Parse directly as chunks for your vector store. Because headings, lists, and tables are preserved instead of flattened, retrieval quality improves — the model gets a coherent section, not fragments stitched together.

4. Compliance and audit trails
For regulated workflows (financial statements, medical intake forms, legal filings), the combination of confidence score and page coordinate means extracted values can be traced back to a location in the source document — which is closer to what most audit processes actually require than "we have the data somewhere."

Closing the loop

Structured elements with reading order, confidence, and bounding boxes are what turn "we extracted some text" into "we extracted data we can act on" — whether that means posting a line item to your ERP, indexing a chunk for RAG, or routing a flagged field to a human.

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.

Key takeaways

A PDF is a presentation format. Structure has to be extracted, not assumed.
Source context — confidence scores and page coordinates — is what makes extracted data traceable back to the source, not just readable.
Match the processing mode (Text / Structure / Understand / Agentic) and request path (Parse / Extract) to the document instead of defaulting to one approach for everything.

How the modes actually perform

The table above tells you when to use each mode. Here's what that difference looks like in numbers — internal benchmark scores (Build #200, July 13, 2026, commit c24e99581f), all on a 0–1 scale where higher is better:

Mode	Overall	NID	NID-S	TEDS	TEDS-S	MHS	MHS-S	Zone-F1
Understand	0.9321	0.9590	0.9567	0.9365	0.9444	0.8671	0.9078	0.6892
Agentic (Vision)	0.9304	0.9572	0.9548	0.9370	0.9444	0.8649	0.9078	0.7006
Structure	0.8923	0.9342	0.9288	0.7386	0.7846	0.8282	0.8884	0.4288
Text	0.8887	0.9263	0.9291	0.7394	0.7902	0.8239	0.8862	N/A

The -S suffix variants (NID-S, TEDS-S, MHS-S) are strict versions of each metric. Zone-F1 measures spatial layout accuracy and doesn't apply to Text mode, which doesn't preserve layout.

What each metric actually measures:

NID (Normalized Information Distance) — how much information survives from the original document. 0.95+ means almost nothing is lost.
TEDS (Tree Edit Distance Score) — table structure accuracy specifically: how well row/column relationships in extracted tables match the source. This is the metric that separates Text/Structure from Understand/Agentic the most — TEDS is the hardest metric for complex documents, and scores below 0.80 are common outside these modes.
MHS (Markdown Heading Score) — whether the heading hierarchy (H1/H2/H3) gets reconstructed correctly.
Zone-F1 — spatial accuracy: whether bounding-box zones (text regions, tables, figures) are correctly detected and labeled. Higher-depth modes (Understand, Agentic) score noticeably better here.

The practical read: Text and Structure hold up fine on NID (they capture the content), but their TEDS scores drop hard on anything with real tables — 0.74 vs 0.93+ for Understand and Agentic. If your documents are table-heavy, that gap is the one to design around, not overall accuracy.

You can see more details here

FAQs

❓ Can I get structured JSON and Markdown from the same request?
✅ Choose the output format based on the use case — structured JSON when you need layout-aware elements with coordinates and confidence, or Markdown when you need clean content for RAG, search, or document Q&A. Check the API docs for the recommended request pattern if a workflow needs both.

❓ Does this replace OCR, or run on top of it?
✅ It replaces the need for a separate OCR step. Structure and Understand modes handle scanned or image-based documents directly through the same API — you don't build or maintain a separate OCR pipeline before extraction.

❓ How do I know which processing mode to use for a given document?
✅ Start with Text mode for born-digital PDFs (fastest, cheapest). Use Structure mode once scanning or OCR is involved. Reach for Understand mode on complex layouts, handwriting, or documents needing OCR correction. Reserve Agentic mode for visually complex or ambiguous documents where deeper reasoning is worth the extra cost.

❓ What happens to my documents after they're processed?
✅ Files are not persistently stored after processing. If you need retention for audit purposes, that's handled on your side, not the API's.

❓ Is there a free way to test this before integrating it?
✅ Yes. Data Extraction API Studio gives you 5,000 free credits, no credit card required, so you can upload your own documents, compare Parse and Extract, try all four modes, and generate a starting schema before writing any code.

Nutrient Data Extraction API
Turn messy PDFs into structured JSON or Markdown your LLM pipeline can trust — with source context on every request.
→ Get started free

Top 7 LLM Observability Tools Every AI Engineer Should Know (2026)

Kevin Meneses González — Wed, 15 Jul 2026 11:57:13 +0000

Artificial intelligence has made it easier than ever to build applications powered by large language models. In just a few hours, you can create a chatbot, a RAG pipeline, or even an autonomous AI agent capable of calling APIs and interacting with external tools.

Getting a demo to work is no longer the hard part.

Running that same application in production — serving hundreds or thousands of users every day — is where the real engineering challenge begins.

Once real traffic starts flowing, developers quickly encounter questions that traditional logging systems cannot answer:

Why did response latency suddenly increase?
Which prompts are consuming the most tokens?
Which customers generate the highest API costs?
What caused this hallucinated answer?
Did the latest prompt update improve or reduce response quality?
Which LLM performs best for this specific task?
How can I debug an AI agent that executed twenty tool calls before failing?

These are exactly the problems that LLM observability platforms are designed to solve.

Instead of treating AI models as mysterious black boxes, observability platforms allow engineering teams to inspect every interaction, measure performance, optimize costs, evaluate outputs, and continuously improve applications running in production.

Whether you're building customer support assistants, financial research tools, coding agents, document-processing systems, or multi-agent workflows, observability has become a critical part of the modern AI stack.

In this article, we'll explore seven of the most popular LLM observability platforms available in 2026 and discuss where each one excels.

What Is LLM Observability?

Traditional application monitoring focuses on metrics like:

CPU usage
Memory
HTTP requests
Database performance
Errors

LLM applications introduce an entirely new layer of complexity.

Every request now contains:

Prompts
Context windows
Retrieved documents
Model parameters
Tool calls
Structured outputs
Token usage
Cost information

Traditional monitoring platforms simply weren't designed for this.

LLM observability extends software monitoring by tracking everything that happens during an AI interaction.

A typical observability platform records:

Prompt execution
Model responses
Token consumption
Cost per request
Latency
User sessions
Agent traces
Tool execution
Prompt versions
Evaluation scores
Errors and failures

This allows developers to understand not only whether something failed, but why it failed.

Why Is It Becoming Essential?

Six months ago, many AI applications consisted of a single API call to GPT-4.

Today's applications are very different.

A single user request may involve:

Vector database retrieval
Multiple prompt templates
Several LLM calls
External APIs
MCP servers
Python execution
Memory retrieval
Human approval
Final answer generation

Without observability, debugging these workflows becomes almost impossible.

As AI systems become more autonomous, engineering teams need visibility into every decision an agent makes.

That's exactly where these platforms provide value.

What Features Matter Most?

Before comparing platforms, it's worth understanding the capabilities that differentiate them.

Tracing

Tracing records every step an AI application performs.

Instead of seeing only the final response, developers can inspect the complete execution path.

For example:

User Question
↓
Retriever
↓
Prompt Template
↓
Claude
↓
Weather API
↓
Second Prompt
↓
Final Response

This dramatically simplifies debugging.

Cost Analytics

LLM costs can grow surprisingly fast.

Good observability platforms answer questions like:

Which user generated the highest cost?
Which prompt consumes the most tokens?
Which model is most cost-efficient?
How much does each feature cost?

This information often leads to significant savings simply by optimizing prompts or routing requests to more appropriate models.

Prompt Versioning

Prompts evolve continuously.

Without versioning, it's difficult to know which change introduced a regression.

Modern platforms allow teams to compare prompt versions and roll back unsuccessful updates.

Evaluation

One of the biggest challenges in AI engineering is measuring quality.

Unlike traditional software, LLM outputs aren't simply "correct" or "incorrect."

Evaluation systems can automatically score responses based on criteria such as:

Accuracy
Relevance
Faithfulness
Hallucination rate
Toxicity
Response quality

Some platforms even use another LLM as an automated judge.

Production Debugging

Imagine a customer reports:

"Your AI gave me the wrong answer yesterday."

Without observability, reproducing that interaction is extremely difficult.

With tracing enabled, engineers can inspect:

The exact prompt
Retrieved documents
Model parameters
Tool calls
Response time
Final output

This dramatically reduces debugging time.

Evaluation Criteria

For this comparison, each platform was evaluated across the areas above: tracing depth, cost analytics, prompt versioning, evaluation capabilities, and production debugging.

1. Langfuse

Best for: Open-source observability with powerful tracing and evaluation features.

Langfuse has quickly become one of the most popular observability platforms for AI applications.

Unlike traditional monitoring software, it was built specifically around LLM workflows.

Its biggest strength is that it combines enterprise-level capabilities with an open-source foundation.

For many engineering teams, this provides the best balance between flexibility and production readiness.

Key Features

End-to-end tracing
Prompt management
Dataset creation
Evaluations
Cost analytics
Session tracking
User analytics
Self-hosted deployment
OpenTelemetry support

One particularly useful capability is visualizing complete execution graphs for AI agents.

Instead of reviewing logs line by line, developers can inspect the entire reasoning pipeline.

This makes debugging dramatically faster.

Pros

✔ Excellent developer experience
✔ Open source
✔ Self-hosting available
✔ Strong documentation
✔ Supports most modern AI frameworks

Cons

Enterprise features require paid plans
Can feel overwhelming for very small projects

Best Use Cases

Production AI applications
RAG systems
AI agents
Multi-agent workflows
Internal enterprise assistants

2. LangSmith

Best for: Teams already building with LangChain and LangGraph.

LangSmith is the observability platform developed by the LangChain team.

Rather than acting as a generic monitoring solution, it's deeply integrated into the LangChain ecosystem.

If your application uses LangGraph agents, LangSmith feels almost like a native debugging interface.

Developers can replay executions, inspect intermediate reasoning steps, compare prompt versions, and evaluate changes over time.

For complex AI agents, this level of visibility becomes invaluable.

Key Features

Agent tracing
Prompt versioning
Dataset management
Human feedback
Automated evaluations
Experiment tracking
Production monitoring

One of LangSmith's strongest capabilities is debugging multi-agent systems where dozens of individual reasoning steps occur before producing a final answer.

Pros

✔ Best integration with LangGraph
✔ Excellent UI
✔ Powerful evaluation system
✔ Enterprise-ready

Cons

Delivers the most value when using the LangChain ecosystem
Less framework-agnostic than some competitors

Best Use Cases

LangGraph agents
Enterprise AI assistants
Coding agents
Research agents
Production agent orchestration

3. Portkey

Best for: Organizations that need both an AI Gateway and observability platform.

Portkey takes a different approach.

Instead of focusing only on monitoring, it sits between your application and the LLM providers.

Think of it as an API gateway designed specifically for AI.

Every request flows through Portkey before reaching OpenAI, Anthropic, Gemini, Mistral, or another provider.

This architecture unlocks capabilities beyond observability.

Developers can:

Route traffic between providers
Retry failed requests
Cache responses
Apply guardrails
Monitor costs
Analyze latency
Centralize logging
Switch providers without changing application code

For larger organizations managing multiple models, this architecture can significantly simplify infrastructure.

Pros

✔ Multi-provider routing
✔ Built-in observability
✔ AI gateway capabilities
✔ Cost optimization
✔ Strong enterprise focus

Cons

More infrastructure to configure
May be unnecessary for very small applications

Best Use Cases

Multi-model applications
Enterprise AI platforms
SaaS products
High-volume API workloads

4. Braintrust

Best for: Evaluating AI applications before they reach production.

While many observability platforms focus on monitoring requests and debugging failures, Braintrust is built around a different question:

"How do we know our AI application is actually getting better?"

This makes Braintrust one of the strongest platforms for AI evaluation.

Instead of simply collecting traces, it helps engineering teams measure whether changes to prompts, models, or workflows improve response quality.

For companies shipping AI products every week, this capability is extremely valuable.

Key Features

Prompt evaluation
LLM-as-a-Judge
Human evaluations
Regression testing
Experiment tracking
Benchmark datasets
CI/CD integration
Team collaboration

Braintrust allows developers to compare prompt versions before deploying them.

For example, after changing a system prompt, you can automatically test it against hundreds of predefined examples and compare the results with the previous version.

This prevents unexpected regressions from reaching production.

Pros

✔ Excellent evaluation workflow
✔ Designed for enterprise AI teams
✔ Strong experiment management
✔ Easy A/B testing

Cons

Less focused on operational monitoring
Better suited for mature AI products than small prototypes

Best Use Cases

AI copilots
Customer support assistants
Enterprise chatbots
Document understanding
AI products with continuous releases ## 4. Braintrust

Best for: Evaluating AI applications before they reach production.

While many observability platforms focus on monitoring requests and debugging failures, Braintrust is built around a different question:

"How do we know our AI application is actually getting better?"

This makes Braintrust one of the strongest platforms for AI evaluation.

Instead of simply collecting traces, it helps engineering teams measure whether changes to prompts, models, or workflows improve response quality.

For companies shipping AI products every week, this capability is extremely valuable.

Key Features

Prompt evaluation
LLM-as-a-Judge
Human evaluations
Regression testing
Experiment tracking
Benchmark datasets
CI/CD integration
Team collaboration

Braintrust allows developers to compare prompt versions before deploying them.

For example, after changing a system prompt, you can automatically test it against hundreds of predefined examples and compare the results with the previous version.

This prevents unexpected regressions from reaching production.

Pros

✔ Excellent evaluation workflow
✔ Designed for enterprise AI teams
✔ Strong experiment management
✔ Easy A/B testing

Cons

Less focused on operational monitoring
Better suited for mature AI products than small prototypes

Best Use Cases

AI copilots
Customer support assistants
Enterprise chatbots
Document understanding
AI products with continuous releases

5. Arize Phoenix

Best for: Advanced AI and ML observability.

Arize AI has been a leader in machine learning observability for several years.

As generative AI adoption accelerated, the company introduced Phoenix, an open-source platform focused on LLM applications.

Phoenix combines traditional ML monitoring with AI-specific capabilities such as prompt tracing and hallucination analysis.

For organizations already operating ML pipelines, this makes Arize a natural evolution.

Key Features

End-to-end tracing
Hallucination analysis
Root cause investigation
Embedding visualization
Retrieval quality analysis
Prompt inspection
OpenTelemetry support

One particularly interesting capability is analyzing retrieval quality in RAG systems.

Instead of simply inspecting prompts, Phoenix helps identify whether poor answers were caused by weak retrieval rather than the language model itself.

Pros

✔ Excellent for RAG systems
✔ Strong open-source offering
✔ Built by an experienced ML company
✔ Enterprise-grade analytics

Cons

More advanced than many teams require
Learning curve is steeper

Best Use Cases

RAG applications
Enterprise search
AI knowledge bases
Internal copilots
Large production systems

6. Humanloop

Best for: Prompt management and collaborative AI development.

Humanloop sits somewhere between an observability platform and a prompt engineering workspace.

Its philosophy is that AI applications should be developed in the same structured way as software.

Instead of editing prompts directly inside source code, teams can version, test, review, and evaluate prompts collaboratively.

For product teams working closely with engineers, this approach can significantly speed up iteration.

Key Features

Prompt management
Version control
Prompt playground
Automated evaluations
Human feedback
Experiment tracking
Team collaboration

Humanloop also makes it easier for non-engineering stakeholders to participate in prompt development without modifying application code.

Pros

✔ Excellent prompt workflow
✔ Clean interface
✔ Strong collaboration features
✔ Easy experimentation

Cons

Less focused on infrastructure monitoring
More valuable for larger teams than solo developers

Best Use Cases

Product teams
AI startups
Internal copilots
Prompt engineering
Customer support AI

7. Helicone

Best for: Fast and simple LLM observability.

Helicone has one of the simplest onboarding experiences in the industry.

In many cases, developers only need to change the API endpoint used by their application.

Immediately afterwards they gain access to:

Request logs
Token usage
Costs
Latency
User analytics
Model comparisons

This simplicity makes Helicone particularly attractive for startups and individual developers.

Instead of spending hours configuring infrastructure, teams can begin monitoring their AI applications almost immediately.

Key Features

API proxy
Cost analytics
Token tracking
Latency monitoring
User analytics
Request history
Prompt inspection

Pros

✔ Extremely easy to deploy
✔ Very developer friendly
✔ Excellent analytics
✔ Minimal setup

Cons

Smaller feature set than enterprise platforms
Less comprehensive evaluation tooling

Best Use Cases

MVPs
SaaS startups
Internal tools
Developer projects
AI prototypes

Which Platform Should You Choose?

The answer depends entirely on your application.

If you're building your first AI application

Start with Helicone.

It provides immediate visibility into costs, latency, and requests without requiring significant infrastructure.

If you prefer open-source software

Langfuse is currently one of the strongest choices.

It combines production-ready observability with the flexibility of self-hosting.

If you're building AI agents with LangGraph

Choose LangSmith.

Its deep integration with the LangChain ecosystem makes debugging significantly easier.

If you use multiple LLM providers

Portkey is an excellent choice.

Its gateway architecture simplifies routing, failover, and centralized monitoring across different models.

If evaluation is your biggest challenge

Choose Braintrust or Humanloop.

Both platforms excel at measuring response quality and comparing prompt versions before deployment.

If you're operating enterprise-scale AI systems

Arize Phoenix provides some of the most advanced observability capabilities available today, particularly for RAG applications and production environments.

Comparison Table

Platform	Open Source	Tracing	Evaluations	Prompt Mgmt	AI Gateway	Best For
Langfuse	✅	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆	⭐⭐⭐⭐☆	❌	Open-source production AI
LangSmith	❌	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	❌	LangGraph & AI Agents
Portkey	❌	⭐⭐⭐⭐☆	⭐⭐⭐☆☆	⭐⭐⭐☆☆	⭐⭐⭐⭐⭐	Multi-LLM Infrastructure
Braintrust	❌	⭐⭐⭐☆☆	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆	❌	AI Evaluation
Arize Phoenix	✅	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆	⭐⭐⭐☆☆	❌	Enterprise AI & RAG
Humanloop	❌	⭐⭐⭐☆☆	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	❌	Prompt Engineering
Helicone	Partial	⭐⭐⭐⭐☆	⭐⭐☆☆☆	⭐⭐☆☆☆	⭐⭐⭐☆☆	Startups & MVPs

FAQs

What is LLM observability?

It is the practice of monitoring prompts, traces, token usage, costs, latency and evaluations for production AI applications.

Which platform should I choose?

Langfuse → Open source
LangSmith → LangGraph
Portkey → Multi-LLM
Braintrust → Evaluation
Arize → Enterprise
Humanloop → Prompt engineering
Helicone → MVPs

Final Thoughts

Observability is becoming as important for AI applications as logging is for traditional software. The right platform helps reduce costs, improve reliability and accelerate debugging.

Let's Work Together

Looking for high-quality technical content for your AI, API, or developer tool?

📧 kevinmenesesgonzalez@gmail.com

💼 https://www.linkedin.com/in/kevin-meneses-gonzalez/

🌐 https://kevinmeneses.com

I'm always open to new collaborations, sponsored content and developer marketing partnerships.

5 Strapi Alternatives Developers Are Actually Switching To in 2026

Kevin Meneses González — Tue, 14 Jul 2026 16:30:48 +0000

For years, Strapi was the answer.

Need a headless CMS? Open source, self-hosted, developer-first. Done.

That's not true anymore. In 2026, developers are switching away from Strapi at a pace that's hard to ignore — not because it got worse, but because the alternatives got dramatically better.

If you're:

migrating a content-heavy Next.js app,
choosing infrastructure for a new product,
or just tired of patching Node dependencies every quarter,

this matters.

The Hidden Cost Nobody Puts in the Pricing Table

Strapi's pitch has always been simple: it's free, it's open source, you own your data.

All true. None of it accounts for what happens after deployment.

Someone has to manage the server. Apply security patches. Handle database migrations when a plugin update breaks your schema. Babysit uptime at 3am when the content API goes down mid-launch.

That someone is usually a developer who'd rather be shipping features.

Teams call this "Type 1 fun" — technically satisfying, but a distraction from the product you're actually trying to build. Strapi Cloud exists specifically to remove this burden.

It also adds a bill.

The Real Problem Isn't Strapi. It's the Definition of "Headless."

For a long time, "headless CMS" meant one thing: a content repository with an API on top.

That bar is too low for 2026.

Content today needs to move across web, mobile, and increasingly AI-driven interfaces — chatbots, agents, voice assistants. A CMS that only stores text and serves it over REST doesn't cut it when your product needs structured, machine-readable content that an LLM can reason over.

The platforms winning in 2026 aren't just "headless." They handle content operations — versioning, AI-assisted authoring, translation pipelines, and increasingly, native support for AI agents and MCP.

That's the real reason developers are re-evaluating their stack.

What to Look for Before You Switch

Before comparing tools, three questions actually matter:

Framework fit. Are you on Next.js, Nuxt, Astro, SvelteKit? Most CMS platforms support all of them via REST, but GraphQL support narrows the field fast.

True cost at scale. Free tiers are easy to compare. What you'll pay at 12–18 months of real usage — seats, API limits, bandwidth — is the number that matters.

Data portability. Can you get your content out in a standard format if you ever need to migrate again? Some platforms make this trivial. Others make it a project.

With that in mind, here are the five alternatives worth your evaluation time.

1. Payload — Best for Next.js and TypeScript-First Teams

Payload is the CMS that made the biggest jump in 2026. Version 3.0 cut its dependency count from 88 to 27, and its local API means content queries run in-process — no network round trip, no rate limits to worry about.

The schema-as-code approach feels familiar if you've used Sanity, but the TypeScript integration goes further: content types generate full types automatically, so there's no any silently leaking through your codebase.

Pros

Local API eliminates network latency for server-side queries
Auto-generated TypeScript types from your schema
Now framework-agnostic — works with Remix, Astro, SvelteKit, not just Next.js

Cons

Younger ecosystem than Strapi's — fewer plugins, fewer Stack Overflow answers
Smaller community means you'll solve more edge cases yourself

Best for: Teams deeply committed to Next.js and TypeScript who want to own their CMS implementation completely.

2. Sanity — Best for Content Operations and Multilingual Projects

Sanity has evolved past the traditional definition of headless CMS. It's positioning itself as a full content operating system — structured content that plugs directly into AI and automation workflows, not just a delivery API.

Teams running large multilingual content pipelines (10+ languages, document-level i18n) consistently point to Sanity's structured content tooling as the deciding factor.

Pros

Strongest developer experience for structured, queryable content (GROQ)
Excellent Next.js integration with Visual Editing and live preview
Handles document-level internationalization cleanly at scale

Cons

Steeper learning curve for teams new to structured content modeling
Pricing can climb fast once you exceed generous free-tier limits

Best for: Engineering-led teams running multilingual content operations who want AI-ready structured data, not just a content store.

Looking for technical content that actually explains your product?
I write developer-first articles and tutorials for API and infrastructure companies — the kind engineers bookmark instead of skip.
→ Let's talk on LinkedIn

3. Directus — Best for Wrapping an Existing Database

Directus takes a different approach entirely: instead of designing a new database for your content, it sits on top of the one you already have.

That single decision makes it the strongest pick for teams with legacy data models who don't want to migrate everything into a new schema just to get a CMS.

Pros

Adds a CMS layer to an existing SQL database without disrupting the schema
AI features aren't locked behind an enterprise tier — bring your own API key
Generous free tier compared to most open-source competitors

Cons

Less opinionated structure means more setup decisions land on you
Custom AI logic still requires building your own plugin

Best for: Teams that already have a database and need a CMS layer without redesigning their data model.

4. Hygraph — Best for GraphQL-Native Architectures

Hygraph (formerly GraphCMS) is built entirely around GraphQL, not bolted onto REST as an afterthought. For teams working with Next.js, React, or Svelte where efficient data fetching matters, this changes the developer experience meaningfully.

Its standout feature is content federation — pulling data from multiple CMS instances, APIs, and databases into a single GraphQL layer. That's a specific use case, but it's one most competitors don't touch at all.

Pros

GraphQL-first design produces cleaner queries and more predictable data shapes
Content federation across multiple sources in one layer
Strong role-based permissions for larger teams

Cons

Overkill if your project doesn't need GraphQL or multi-source federation
Smaller plugin ecosystem than Strapi or Sanity

Best for: Composable architectures pulling content from multiple sources into a single, unified API.

5. NomaCMS — Best for AI-Native, Zero-Infrastructure Teams

NomaCMS is the newest name on this list, and the one built specifically for the AI-agent era. It's a fully managed, AI-native headless CMS — REST API, JavaScript SDK, and built-in AI tools for writing, translation, and editing, with content and assets served over a global CDN.

You run no CMS server at all. It also ships with official MCP support, meaning tools like Claude Code and Cursor can interact with your content model directly — a detail that matters if your workflow already leans on AI agents for content operations.

Pros

Zero server management — content, assets, and CDN handled entirely by the platform
Native MCP support for AI coding assistants
Fast to start: 7-day free trial, plans from $15/month

Cons

Newer platform — smaller track record than established players
Less customization depth than a self-hosted, code-first CMS

Best for: Small teams and solo developers who want Strapi-like structured content without running Node infrastructure, especially if AI tooling is already part of the workflow.

A Quick Look at Consuming a Modern CMS API

Regardless of which platform you pick, the integration pattern looks similar. Here's a minimal example fetching structured content over REST:

import requests

API_URL = "https://api.example-cms.com/v1/content/articles"
HEADERS = {"Authorization": "Bearer YOUR_API_KEY"}

response = requests.get(API_URL, headers=HEADERS)
articles = response.json()

for article in articles["data"]:
    print(article["title"], "-", article["publishedAt"])

Building a Faster Checkout Flow - 2026-06-02
Why We Moved Off Strapi - 2026-05-14
Structured Content for AI Agents - 2026-04-28

From here you can build:

a content sync pipeline into your own database
an AI agent that queries your CMS directly via MCP
automated translation workflows triggered on publish

Key Takeaways

Strapi still works — but self-hosting only pays off when it's a genuine requirement, not a cost-saving assumption.
The best pick depends on one variable more than any other: do you need code-first flexibility (Payload, Directus) or managed content operations (Sanity, NomaCMS)?
AI-native support — MCP, agent access, structured data for LLMs — is quickly becoming a baseline expectation, not a bonus feature.

FAQs

❓ Is Strapi still a good choice in 2026?
✅ Yes, if self-hosting and full data ownership are non-negotiable requirements. For teams without strong DevOps capacity, the operational overhead often outweighs the savings from a free license.

❓ What's the best headless CMS for a Next.js project?
✅ Payload and Sanity both offer deep Next.js integrations. Payload edges ahead for teams that want a TypeScript-first, code-driven workflow with no external CMS server to manage.

❓ Do any of these support AI agents directly?
✅ NomaCMS ships with native MCP support, letting tools like Claude Code query and manage content directly. Directus and Payload support AI through custom plugins using your own API keys.

The CMS market spent a decade converging on Strapi as the default.

That convergence is over. Pick based on what your team actually needs to maintain — not which platform has the most GitHub stars.

If you're building something and want a second opinion on your content infrastructure, or want your product explained through content developers actually read, you know where to find me: kevinmeneses.com

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

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