Every expense tracker, accounting tool, and bookkeeping app eventually hits the same wall: turning a photo of a receipt into usable data. Raw OCR gives you a blob of text, not structured fields — and building a reliable parser on top is a rabbit hole.
So I built a small API that does one thing well: receipt or invoice in (image or PDF), clean structured JSON out.
What you get back
Every field, every time (null if missing) — so you can skip defensive parsing:
{
"document_type": "receipt",
"merchant": { "name": "...", "address": "...", "phone": "..." },
"date": "2026-06-25", "time": "09:14", "currency": "USD",
"line_items": [
{ "description": "Cappuccino", "quantity": 2, "unit_price": 3.50, "total": 7.00 }
],
"subtotal": 16.75, "tax": 1.51, "tip": 3.00, "total": 21.26,
"payment": { "method": "visa", "card_last4": "4242" }
}
curl -X POST 'https://receipt-extraction-api.p.rapidapi.com/v1/extract' \
-H 'content-type: application/json' \
-H 'X-RapidAPI-Key: YOUR_KEY' \
-H 'X-RapidAPI-Host: receipt-extraction-api.p.rapidapi.com' \
-d '{"image_url": "https://example.com/receipt.jpg"}'
No problem — that's **totally normal** and not your fault. HN restricts "Show HN" for brand-new accounts (anti-spam). It's **not blocked forever** — once your account has a little history/karma (comment thoughtfully on a few threads over a week or two), Show HN opens up. **Park HN for later.** Your post did *not* go out, so nothing to undo.
Let's keep rolling. 👇
---
## 🟢 POST #3 — dev.to (article)
**Why:** no restrictions for new accounts, it's evergreen, and it ranks in Google — a long-tail traffic source that keeps working.
**Go to:** [dev.to/new](https://dev.to/new) (sign in with GitHub — instant)
**Title:**
I built a Receipt/Invoice → JSON API (here's how, and how to use it)
**Tags** (type these in the tags field):
api, showdev, ai, webdev
**Body** (paste this whole block — it's Markdown, which dev.to uses natively):
Every expense tracker, accounting tool, and bookkeeping app eventually hits the same wall: turning a photo of a receipt into usable data. Raw OCR gives you a blob of text, not structured fields — and building a reliable parser on top is a rabbit hole.
So I built a small API that does one thing well: receipt or invoice in (image or PDF), clean structured JSON out.
What you get back
Every field, every time (null if missing) — so you can skip defensive parsing:
{
"document_type": "receipt",
"merchant": { "name": "...", "address": "...", "phone": "..." },
"date": "2026-06-25", "time": "09:14", "currency": "USD",
"line_items": [
{ "description": "Cappuccino", "quantity": 2, "unit_price": 3.50, "total": 7.00 }
],
"subtotal": 16.75, "tax": 1.51, "tip": 3.00, "total": 21.26,
"payment": { "method": "visa", "card_last4": "4242" }
}
Using it
curl -X POST 'https://receipt-extraction-api.p.rapidapi.com/v1/extract' \
-H 'content-type: application/json' \
-H 'X-RapidAPI-Key: YOUR_KEY' \
-H 'X-RapidAPI-Host: receipt-extraction-api.p.rapidapi.com' \
-d '{"image_url": "https://example.com/receipt.jpg"}'
It also accepts image_base64 (+ media_type) or pdf_base64.
Why a fixed schema
The annoying part of receipt parsing isn't the OCR — it's getting consistent, typed output you can trust. This API always returns the same shape, with null for anything it can't find, so your code never has to guess.
Try it
Live demo (watch an image turn into JSON): https://receipt-extraction-api.onrender.com
- Free tier (50 calls/mo) + paid plans: https://rapidapi.com/DenisCj1/api/receipt-extraction-api
I'd love feedback — especially edge cases: handwritten receipts, multi-page invoices, non-USD currencies. What would make this genuinely useful in your stack?
Top comments (0)