I run into the same conversation every time I talk to someone building a job board or ATS tool:
"How do you handle job description parsing?"
"...we just have employers fill in a form manually."
"And if they paste a raw JD?"
"We kind of... hope for the best."
That's the gap. Affinda parses JDs well, but their entry plan starts around $800/month with a sales call requirement. There's no self-serve option, no free trial you can actually test with real data, and no pricing that makes sense for an indie job board doing 200 postings a month.
So I built JD Intelligence — a self-serve JD parsing API at $29/mo with a 7-day free trial and no sales call.
What it does
Four endpoints:
POST /parse — Takes raw job description text, returns 16 structured fields:
- Job title (normalised)
- Salary min/max + currency
- Required skills (array)
- Nice-to-have skills (array)
- Seniority level
- Employment type
- Remote policy
- Location
- Visa sponsorship
- Education requirements
- Years of experience
- Industry
- Department
- Benefits
- Application deadline
- Language requirements
POST /score — Takes a resume + job description, returns an ATS compatibility score with field-by-field breakdown. Useful for job matching, resume screening, candidate ranking.
POST /enrich — Rewrites a JD for clarity, inclusive language, and better structure. Removes jargon, separates must-haves from nice-to-haves, standardises formatting. Returns the rewritten JD plus a diff of changes made.
POST /classify — Tags a JD with department, function, industry, and seniority. One call, clean JSON. Useful for job board taxonomy and SEO page generation.
The tech stack
- FastAPI for the API layer — fast, clean, automatic OpenAPI docs
- Claude API for the actual parsing/enrichment/classification — far more reliable than regex or fine-tuned models for understanding messy real-world JD text
- Redis for response caching — same JD hit twice doesn't cost twice
- Railway for hosting — zero-config deploys, easy environment management
- Stripe for billing — metered usage + subscription tiers
Why Claude for parsing?
I tried a few approaches before landing on this. Rule-based extraction with spaCy works fine for structured JDs but falls apart on the noisy ones — missing salary ranges buried in paragraphs, skills listed as "experience with the Adobe suite" instead of named tools, seniority implied by responsibilities rather than stated directly.
Claude handles that ambiguity well. A JD that says "you'll be leading a small team of engineers and reporting to the CTO" correctly gets classified as senior/lead level. A JD that says "competitive compensation" with a Glassdoor link in the footer gets flagged as salary-not-disclosed rather than hallucinating a number.
The tradeoff is cost and latency. Each /parse call takes 1-3 seconds and costs a few cents in Claude API usage. That's fine for job board use cases (you're parsing when a JD is submitted, not on every page load), but it's something to be aware of.
The caching layer
Redis caching on a hash of the JD text means if the same JD gets submitted twice — which happens constantly with job boards syndicating listings — the second call is instant and free. Cache TTL is 24 hours. This cuts real-world API costs significantly.
Current state
Launched this week. $29/mo for 200 parses, 7-day free trial, instant API key.
Live demo with no signup at jdintelligence.dev/demo — paste any real job description and see the JSON output.
Docs at jdintelligence.dev/docs.
What I'm looking for
Feedback from anyone building in this space — job boards, ATS tools, recruiting agents, resume matching tools. Is /score useful or does the matching need to be more configurable? Is 200 parses/mo the right entry tier?
If you're building something where structured JD data would help, I'd love to talk through the use case.
Top comments (0)