DEV Community: William March

The SEC has a free financial data API that nobody talks about

William March — Wed, 24 Jun 2026 09:39:27 +0000

Every quarterly earnings number for every US public company going back to 2009 is sitting in a free, well-documented JSON API run by the US government. No API key. No rate limit for normal use. No paywall. Almost nobody in the dev community seems to know it exists.

It's at data.sec.gov, and it's the same data Bloomberg charges $24k/year for.

What's in it

The SEC requires all US-listed companies to file financial reports in XBRL — a structured XML format where every number is tagged with a standardised concept name. The EDGAR system has been collecting these since around 2009. The companyfacts endpoint exposes all of it as clean JSON:

GET https://data.sec.gov/api/xbrl/companyfacts/CIK{cik}.json

Where CIK is the company's SEC identifier (10 digits, zero-padded). For Apple, that's 0000320193. The response is a large JSON object with every concept the company has ever reported, broken down by period.

The other endpoint you need is the ticker-to-CIK map:

GET https://www.sec.gov/files/company_tickers.json

This gives you a flat list of all US-listed companies with their CIK, ticker, and name. Load it once and cache it.

One gotcha: concept names vary by company

Companies don't all use the same GAAP concept names to report the same thing. Apple reports revenue as RevenueFromContractWithCustomerExcludingAssessedTax. Older companies use Revenues. Some use SalesRevenueNet. If you just look up one concept name, you'll get blanks for most companies.

The fix is a concept alias map: try each name in order, use the first one that has data.

const CONCEPT_MAP: Record<string, string[]> = {
  revenue: [
    'Revenues',
    'RevenueFromContractWithCustomerExcludingAssessedTax',
    'RevenueFromContractWithCustomerIncludingAssessedTax',
    'SalesRevenueNet',
    'SalesRevenueGoodsNet',
  ],
  netIncome: [
    'NetIncomeLoss',
    'NetIncomeLossAvailableToCommonStockholdersBasic',
    'ProfitLoss',
  ],
  operatingCashFlow: [
    'NetCashProvidedByUsedInOperatingActivities',
    'NetCashProvidedByUsedInOperatingActivitiesContinuingOperations',
  ],
  capex: [
    'PaymentsToAcquirePropertyPlantAndEquipment',
    'PaymentsForCapitalImprovements',
    'CapitalExpenditureDiscontinuedOperations',
  ],
};

function pickConcept(facts: CompanyFacts, names: string[]) {
  for (const name of names) {
    const concept = facts['us-gaap']?.[name];
    if (concept?.units?.USD?.length) return concept.units.USD;
  }
  return null;
}

Another gotcha: Q4 doesn't exist

Companies file 10-Qs for Q1, Q2, Q3. They never file a 10-Q for Q4 — that's folded into the annual 10-K. So the API has no Q4 row.

You synthesise it: Q4 = FY - (Q1 + Q2 + Q3).

This works for flow metrics (revenue, net income, cash flows). For balance sheet items (total assets, equity), they're point-in-time stocks — carry the year-end figure as Q4 rather than doing the arithmetic, because it's the same date.

function synthesiseQ4(
  quarters: Period[],
  annual: Period[]
): Period[] {
  return annual.map(fy => {
    const q1 = quarters.find(q => q.fy === fy.fy && q.fp === 'Q1');
    const q2 = quarters.find(q => q.fy === fy.fy && q.fp === 'Q2');
    const q3 = quarters.find(q => q.fy === fy.fy && q.fp === 'Q3');
    if (!q1 || !q2 || !q3) return null;
    return {
      fy: fy.fy,
      fp: 'Q4',
      end: fy.end,
      val: fy.val - q1.val - q2.val - q3.val,
    };
  }).filter(Boolean);
}

Free cash flow: derive it yourself

Free cash flow isn't an XBRL concept — no company files it. You compute it from the two inputs that are in the data:

FCF = operating cash flow - capex

CapEx is reported as a positive outflow (the company paid $X), so you subtract it. The result is the cash a business generates after maintaining and growing its assets — the number that actually matters for valuation.

The User-Agent requirement

One thing that'll get you 403'd: the SEC requires a non-empty, descriptive User-Agent header with a contact email. Generic headers like Mozilla/5.0 will be rejected.

const headers = {
  'User-Agent': 'YourAppName contact@yourdomain.com',
  'Accept': 'application/json',
};

Use your real email. SEC enforcement is light, but it's a public data service and they ask for it so they can contact you if your scraper goes rogue.

Rate limits

The official guidance is 10 requests/second per IP for the EDGAR APIs. For normal programmatic use you won't hit that. If you're building something with a lot of users hitting it simultaneously, cache aggressively — the underlying data changes at most a few times per quarter.

A Cache-Control: s-maxage=3600, stale-while-revalidate=86400 on your own API layer keeps the SEC request volume low even under traffic.

What you get for free

Revenue, net income, EPS, equity for every US public company back to ~2009
Full filing history (every 10-K, 10-Q, 8-K, proxy) via data.sec.gov/submissions/CIK{cik}.json
Clean JSON, no parsing, no scraping
All of it public domain — no license restrictions, no attribution requirements

For most retail-scale use cases, this is everything you need. Bloomberg's $24k/year buys you analyst estimates, real-time quotes, transcripts, and Excel integration on top of this. But the underlying SEC data? Free.

I built Finterm as a free browser-based EDGAR viewer on top of this API — it handles the concept aliasing, Q4 synthesis, and FCF calculation so you can just type a ticker and see the numbers. The full writeup on how it's built (Cloudflare Workers, no Redis, WebGL charts) is on the blog.

I built a financial terminal in the browser because Bloomberg costs $24k/year and I have opinions

William March — Wed, 17 Jun 2026 15:21:24 +0000

The financial data industry runs on vibes and legacy software. Bloomberg Terminal: $24,000/year for a keyboard from 1983 and a UI that looks like it was designed by someone who genuinely hates users. Koyfin: prettier, but $600/year and you're still just renting access to the same SEC filings that are public domain.

I built Finterm — a keyboard-first browser terminal for stocks and crypto. Free tier is actually free, data comes from public sources, and the whole thing runs on Cloudflare Workers at the edge. Here's what building it taught me.

The platform constraint that broke all my dependencies

I deployed to Cloudflare Workers instead of a Node.js server. This was either the smartest or dumbest decision depending on the day.

Workers runs V8 isolates, not Node. This means: no fs, no crypto module (as you know it), no bcrypt, no axios, no cheerio, no jsdom. Half of npm just... doesn't work.

Password hashing is where I have to be honest: bcryptjs actually runs on Workers if you enable the nodejs_compat flag, which exposes most of node:crypto including crypto.randomBytes. Not a hard blocker. But I swapped it out for @noble/hashes anyway — pure JS Argon2id, zero Node-compat surface area, and OWASP currently recommends Argon2id over bcrypt for new password storage because it's more memory-hard. The platform pushed me to look at the options, and the better option was right there.

The SEC data layer was next. The old code used axios and cheerio to scrape HTML. Both fail on Workers. But scraping was wrong anyway — SEC's EDGAR has a proper JSON API at data.sec.gov that barely anyone uses. You get typed company facts, filing histories, the whole thing. No parsing required. The constraint forced the right architecture.

Getting financial data for free (and why Bloomberg is a scam)

Bloomberg's entire moat is: we have the data and you don't. But for US equities, the SEC requires public companies to file machine-readable XBRL data. Every quarterly earnings number, every balance sheet line item, every cash flow figure — it's all in the public domain at data.sec.gov/api/xbrl/companyfacts/.

The fun part is that companies don't all use the same GAAP concept names. Apple reports revenue under RevenueFromContractWithCustomerExcludingAssessedTax. Other companies use Revenues. Some use SalesRevenueNet. You have to build a concept alias map and pick the first one that has data for the period you're looking for:

const CONCEPT_MAP = {
  revenue: [
    'Revenues',
    'RevenueFromContractWithCustomerExcludingAssessedTax',
    'RevenueFromContractWithCustomerIncludingAssessedTax',
    'SalesRevenueNet',
    'SalesRevenueGoodsNet',
  ],
  // ...30 more metrics
};

The other gotcha: SEC only gives you Q1, Q2, Q3, and FY. There's no Q4 row. You have to synthesise it: Q4 = FY - (Q1 + Q2 + Q3). But this only works for flow metrics (revenue, net income, cash flow). Balance sheet metrics are point-in-time stocks — you just carry the FY close value as Q4 because it's the same date.

Free cash flow isn't in XBRL at all. You derive it: FCF = operating cash flow - capex. And capex is reported as a positive outflow (you paid $X), so you subtract it, not add.

Bloomberg charges you $24k/year partly for someone to have already figured all this out.

A data gateway instead of Redis

The obvious architecture for caching upstream API responses is: Redis. Call upstream, cache in Redis, return to client. This is also the architecture that costs $40/month for Upstash before you've written a line of product code.

The alternative: route everything through a single Next.js API route and let Cloudflare cache it at the edge.

GET /api/data/binance/ticker24?symbol=BTCUSDT
GET /api/data/sec/quarterly?ticker=AAPL
GET /api/data/fred/series?id=DFF

Every endpoint returns Cache-Control: s-maxage=N, stale-while-revalidate=86400. Price feeds get s-maxage=5. SEC filings get s-maxage=3600. Cloudflare's CDN absorbs the cache hits before they ever reach the worker. Rate limiting only fires on cache misses — exactly the traffic you actually want to throttle.

No Redis. No Upstash. No cache invalidation logic. Just HTTP semantics working as designed.

Dual-layer rate limiting

Cloudflare Workers has a native rate limiting binding — sub-millisecond, sliding window, in-memory at the edge. But it's eventually consistent across colos. During the ramp-up window, a burst of 10-30 parallel requests from one IP can slip through before the state propagates.

So there are two layers:

Layer 1 — Cloudflare's binding: 600 req/min for hot price feeds, down to 5 req/min for bulk registry fetches. Catches sustained abuse.

Layer 2 — Per-isolate in-memory burst cap: a Map<key, timestamp[]> that enforces a per-second limit from a single isolate's perspective. Doesn't share state across isolates, but nails the runaway curl loop and rogue browser tabs immediately while the CF binding catches up globally.

const BURST_PER_SEC = {
  heavy: 4,   // 4/sec/isolate
  bulk:  1,   // one registry fetch per second is plenty
};

The CF binding cap catches scraper farms. The in-memory burst catches the single idiot with a while(true) { fetch() } loop. Both are necessary.

WebGL charts (not TradingView widgets)

Koyfin's charts are TradingView widgets. They're fine. They're also somebody else's software bolted onto your product, and you can't touch the renderer.

Finterm's chart is a custom WebGL renderer — candlesticks, volume bars, crosshair, axes, drawings, indicators, all built from scratch. The reason to go WebGL is simple: you want 5,000 candles to render in under a frame at 60fps. Canvas 2D can't do it. The DOM definitely can't.

The tricky part was zoom/pan feel. The naive implementation is: on wheel event, call zoomAt(factor, x). This produces stair-step motion — each wheel tick snaps the view to a new discrete state. TradingView doesn't do that, and it's why TradingView feels smooth.

The fix is RAF-eased momentum. Wheel events accumulate into a target zoom level; each animation frame eases toward it with a decay function. Pan has a sub-pixel offset — fractional bar positions accumulate in a float, and only integer amounts get folded into the data slice. The residual is applied as a matrix translation so the candles actually slide between positions rather than jumping bar-by-bar.

Getting this right took two weeks and about forty rewrites of the interaction handler. "Don't touch ZOOM_DIVISOR = 2500 or MAX_DELTA = 0.012" is now in the codebase docs.

Indicators in a sandboxed Web Worker

Users can write custom indicators in JavaScript. This is a sandbox problem.

The solution is a Web Worker that evaluates user code with Function(), feeds it the candle history, and enforces a 1-second timeout. The worker is the sandbox — if the code hangs or throws, you terminate the worker and return an error, and the main thread never blocks.

The contract is deliberately minimal: candles in, { outputs, series } out. Users can implement VWAP, MACD, Supertrend, whatever they want, in ~10 lines of JS. The built-in presets (SMA, EMA, Bollinger Bands, RSI) ship as code strings evaluated through the same sandbox, so there's exactly one code path.

Pop-out windows and the `ownerDocument` problem

Every chart window has a popout button that calls window.open() and renders the full React component tree into the opened window's document via createRoot. This is not a common pattern.

The bug you hit immediately: addEventListener('mousemove', handler) resolves to the parent window's event target, not the popout's. So drag events stop working. matchMedia queries the parent window's viewport. innerWidth returns the wrong number.

The fix is useOwnerWindow:

export function useOwnerWindow(ref: RefObject<HTMLElement | null>): Window {
  const [win, setWin] = useState<Window>(() => window);
  useEffect(() => {
    const next = ref.current?.ownerDocument?.defaultView;
    if (next && next !== win) setWin(next);
  });
  return win;
}

Every component that attaches DOM events uses this instead of the global window. Similarly, any document.createElement for offscreen canvas nodes goes through node.ownerDocument.createElement so it belongs to the right document.

Plain JSX, fetch, and ResizeObserver are document-agnostic and just work. The only things that care about which window they're in are event listeners and layout queries.

The state of financial tooling

Bloomberg's defensible moat is mostly institutional inertia and the Excel add-in. Koyfin's moat is a better UX than Bloomberg, which is a low bar. Neither is particularly hard to build around for retail-scale use cases.

The data is out there. The EDGAR API is excellent and underused. Binance's REST and WebSocket APIs are clean and fast. FRED has decades of macro data at api.stlouisfed.org. CoinGecko's free tier is genuinely generous.

The hard part isn't access. It's building a data gateway that caches correctly, rate-limits sanely, and doesn't wake you up at 3am because you forgot to pay the Redis bill.

Finterm is live at finterm.xyz. Free to use.

What breaks when you ship Next.js on Cloudflare Workers

William March — Sat, 16 May 2026 19:20:09 +0000

I've been building Finterm, a financial terminal
that runs entirely in a browser tab, on Cloudflare
Workers via @opennextjs/cloudflare. The promise
is the obvious one — global edge runtime,
near-zero cold starts, pay-per-request pricing.
The catch is that Workers don't run Node.js. Every
package in your dependency tree has to work in
the Workers runtime, and a surprising number of
common ones don't.

This is a rough log of what I had to rip out and
what I replaced it with, plus a couple of patterns
that turned out to be necessary on Workers but
irrelevant on Node.

## bcrypt → Argon2id via @noble/hashes

bcryptjs reaches for crypto.randomBytes and a
few other Node primitives that aren't polyfilled
in Workers. Argon2id is the modern alternative
anyway, and @noble/hashes exposes a pure-JS
implementation that runs anywhere and lines up
with current OWASP guidance. The migration was a
one-line change in the password hasher plus a
re-hash on next login.

## cheerio / jsdom / parse5 → htmlparser2

For the news reader I needed to extract article
bodies from arbitrary HTML. cheerio pulls in
parse5, which doesn't run on Workers, and
jsdom is even further away from compatibility.
htmlparser2 is SAX-style streaming and pure JS,
so it runs anywhere — but you have to walk the
events yourself rather than querying a tree. Worth
it for the runtime portability.

## The Yahoo Finance crumb handshake

Not a Workers issue specifically, but I hit it
harder because of Workers. Yahoo's quoteSummary,
options, and profile endpoints require a session
cookie and a crumb token bound to that session.
The dance: first you GET https://fc.yahoo.com/,
which returns 404 with Set-Cookie for A1 and A3;
then you GET /v1/test/getcrumb with those
cookies, which returns the crumb as plain text;
then every gated request needs that cookie plus
&crumb=... appended to the URL.

  const seed = await fetch('https://fc.yahoo.com/',
  { headers: BROWSERY });
  const cookie = seed.headers.getSetCookie()
    .map(c => c.split(';')[0])
    .filter(c => c.startsWith('A1=') ||
  c.startsWith('A3=') || c.startsWith('A1S='))
    .join('; ');
  const crumbRes = await fetch('https://query1.finan
  ce.yahoo.com/v1/test/getcrumb', {
    headers: { ...BROWSERY, Cookie: cookie },
  });
  const crumb = (await crumbRes.text()).trim();

A few gotchas. The getcrumb endpoint returns
text/plain, not JSON, so you can't send an
Accept: application/json header — it'll 406. The
User-Agent has to look browsery; a plain
curl/8.x or your fetch library's default gets
rate-limited fast. The cookie and crumb stay valid
for roughly thirty minutes, after which you
re-handshake. I cache the pair per-isolate and
refresh on the first 401.

## Single outbound gateway

Workers isolates are short-lived but they do
persist module state across requests on a single
isolate, which makes the obvious caching patterns
work better than on a per-request serverless
model.

Every upstream HTTP call in the app goes through
one route — /api/data/[...path]. The route looks
up the endpoint by path, runs the provider
function, attaches Cache-Control: s-maxage=N, stale-while-revalidate=86400, and lets the
Cloudflare edge cache do the heavy lifting. A
four-tier per-IP rate limiter only fires on cache
misses, so a popular ticker can be served to
thousands of users without ever hitting Yahoo or
SEC again that minute.

This pattern also gave me a single chokepoint for
an SSRF guard, so user-supplied paths can't reach
back into Cloudflare's metadata service or some
internal hostname.

## Pop-outs that share React state

Off the Workers topic but a fun one. Each window
in the dashboard has a popout button. It calls
window.open('/popout.html'), then React-renders
the same component switch into the popout's
document. The popout writes back to the parent's
workspace state through a callback, so edits
round-trip in real time.

Two non-obvious things had to change in the
window-body components. Any addEventListener or
matchMedia has to be bound to the popout's own
window (I expose this through a
useOwnerWindow(ref) hook). And any
document.createElement for an offscreen canvas
has to go through
someExistingNode.ownerDocument.createElement so
the node belongs to the popout's DOM rather than
the parent's.

## Result

Finterm is live at
finterm.xyz — open it, type
a ticker, and a chart, SEC fundamentals, options
chain with Greeks, and analyst estimates open as
draggable windows. Everything described above runs
in Cloudflare's edge: no Node server, no cold
starts to speak of.

Happy to go deeper on any of the above if there's
interest.

Drop-in AI Chat for Any Website — No Framework Required

William March — Thu, 16 Apr 2026 11:53:11 +0000

I was building a website builder platform and needed an AI assistant that could talk to users, call backend functions, and drop into any page without coupling to a framework. Everything I found was tied to React or required a backend SDK. So I built my own.

What it does

aichats renders a floating chat button on your page. Click it, chat opens. The LLM handles conversation and when it needs to do something — search products, create a ticket, query a database — it calls your tools automatically.

The full tool-calling loop runs without manual orchestration. You define tools, the LLM decides when to call them, the plugin executes them, feeds results back, and the LLM responds.

npm install aichats

Quick start — script tag

Drop this on any HTML page:

<script src="https://unpkg.com/aichats/dist/ai-chat-plugin.js"></script>
<script>
  AIChatPlugin.create({
    apiKey: "sk-...",
    provider: "openai",
    systemPrompt: "You help customers find products.",
    tools: [
      {
        type: "function",
        function: {
          name: "search_products",
          description: "Search the product catalog",
          parameters: {
            type: "object",
            properties: { query: { type: "string" } },
            required: ["query"],
          },
        },
      },
    ],
    actionEndpoint: "/api/chat",
  });
</script>

ES Module

import { create } from "aichats";

create({
  provider: "anthropic",
  apiKey: "sk-ant-...",
  model: "claude-sonnet-4-6",
  systemPrompt: "You are a helpful assistant.",
  tools: TOOLS,
  actionEndpoint: "/api/chat",
});

Next.js

"use client";
import { useEffect } from "react";

export default function Chat() {
  useEffect(() => {
    import("aichats").then((mod) => {
      mod.create({
        provider: "openai",
        apiKey: process.env.NEXT_PUBLIC_AI_KEY!,
        tools: TOOLS,
        actionEndpoint: "/api/chat",
      });
    });
  }, []);
  return null;
}

Tool calling — the interesting part

Define tools with the OpenAI function-calling schema. The plugin handles the loop:

User sends message
LLM responds with text, tool calls, or both
Plugin executes each tool call against your endpoint
Results fed back to the LLM
Repeat until the LLM responds with just text

Your server receives:

{ "action": "search_products", "args": { "query": "shoes" } }

And responds:

{ "result": "[{\"name\": \"Running Shoes\", \"price\": 89.99}]" }

The LLM reads the result and summarises it for the user.

Or handle tools client-side — no server needed:

create({
  onAction: async (name, args) => {
    if (name === "get_cart") return JSON.stringify(cartStore.getItems());
    return "Unknown action";
  },
});

Server route examples

Next.js App Router:

// app/api/chat/route.ts
import { NextResponse } from "next/server";

export async function POST(request: Request) {
  const { action, args } = await request.json();

  switch (action) {
    case "search_products": {
      const products = await db.product.findMany({
        where: { name: { contains: String(args.query) } },
        take: 10,
      });
      return NextResponse.json({ result: JSON.stringify(products) });
    }
    default:
      return NextResponse.json({ result: `Unknown: ${action}` });
  }
}

Express:

app.post("/api/chat", async (req, res) => {
  const { action, args } = req.body;

  switch (action) {
    case "search_products": {
      const { rows } = await pool.query(
        "SELECT * FROM products WHERE name ILIKE $1 LIMIT 10",
        [`%${args.query}%`]
      );
      return res.json({ result: JSON.stringify(rows) });
    }
    default:
      return res.json({ result: `Unknown: ${action}` });
  }
});

FastAPI:

@app.post("/api/chat")
async def chat(body: ChatAction):
    if body.action == "search_products":
        rows = await pool.fetch(
            "SELECT * FROM products WHERE name ILIKE $1 LIMIT 10",
            f"%{body.args['query']}%"
        )
        return {"result": json.dumps([dict(r) for r in rows])}
    return {"result": f"Unknown: {body.action}"}

Theming

All CSS custom properties. Override on your page — no build step:

/* Dark theme */
:root {
  --acp-primary: #6366f1;
  --acp-bg: #0f172a;
  --acp-text: #e2e8f0;
  --acp-border: #334155;
}

/* Size */
:root {
  --acp-width: 480px;
  --acp-height: 700px;
}

/* Brand colours */
:root {
  --acp-primary: #16a34a;
  --acp-blue: #16a34a;
  --acp-blue-light: #f0fdf4;
}

Mobile responsive — goes fullscreen under 480px automatically.

Under the hood

Zero dependencies — just HTML, CSS, JS
~30KB minified
Multi-provider: OpenAI, Anthropic, LM Studio, Ollama (any OpenAI-compatible API)
Expand/collapse panel with keyboard support
Proxy support for CORS (local models on different ports)
Max iteration cap to prevent runaway tool loops
Runtime API: setTools(), setSystemPrompt(), send(), clear(), destroy()
TypeScript types included

All config options

Option	Type	Default	Description
`provider`	`"openai" \	"anthropic" \	"lmstudio"`
`apiKey`	`string`	required	API key (stays client-side)
`model`	`string`	provider default	Model override
`baseUrl`	`string`	provider default	Base URL override
`proxyUrl`	`string`	—	Route all LLM requests through a proxy
`systemPrompt`	`string`	—	System prompt
`tools`	`ToolDef[]`	`[]`	Tools the LLM can call
`actionEndpoint`	`string`	—	Server URL for tool execution
`onAction`	`(name, args) => Promise<string>`	—	Client-side tool handler
`maxIterations`	`number`	`8`	Max tool round-trips per message
`title`	`string`	`"AI Chat"`	Header title
`position`	`"bottom-right" \	"bottom-left"`	`"bottom-right"`