--- title: "Resume parser API: the real options, and the half nobody sells you" description: "[NewSearch millions of jobs from your AI agent with MCP→](/blog/jobspipe-mcp-server)" canonical: https://jobspipe.dev/blog/resume-parser-api last_updated: 2026-09-04 --- [NewSearch millions of jobs from your AI agent with MCP→](/blog/jobspipe-mcp-server) [All posts](/blog) ![](/listly/card-field.png) GuideResume Guide·Aug 30, 2026·8 min read # Resume parser API: the real options, and the half nobody sells you Turning a PDF CV into structured JSON is a solved problem with four kinds of vendor behind it - consolidated incumbents like Textkernel, mid-market APIs like Affinda and HrFlow, commodity marketplace endpoints at $29.99 a month, and a roll-your-own LLM. Here is what each actually extracts, what the accuracy claims are worth, and the part every parser vendor leaves out: a parsed resume is useless without a normalized job corpus to match it against. ![Dvir Atias](/authors/dvir-atias.jpg) Dvir Atias Founder, JobsPipe Every recruiting product eventually hits the same wall: a candidate uploads a PDF, and you need name, email, employers, dates, education and skills out of it as JSON. Resume parsing is old technology - the incumbents have been at it for two decades - but the market is more consolidated and more oddly priced than a first search suggests. This is what the real options extract, what their accuracy numbers are worth, and the piece none of them sell you. ## What a parser actually returns The field set is broadly standard across vendors. Affinda’s output covers name, contact details, websites, location, total years of experience, right-to-work status, relocation willingness, availability, work experience (title, organization, dates, employment type, location, description), education (organization, accreditation, level, major, dates, grade), skills, languages with proficiency levels, projects and referees. HrFlow.ai advertises “60+ data points” over much the same ground. Two things vary far more than the field list. The first is input tolerance: Affinda accepts PDF, DOC, DOCX, TXT, RTF, HTML, PNG, JPG, TIFF, ODT, XLS and XLSX including scans and photographs, across 50+ languages. RChilli handles 40+ languages and a similar document spread. HrFlow covers 43+ languages. A commodity marketplace endpoint may take only PDF and Word, and be honest that it is English-first. The second is what happens after extraction. Raw strings are cheap;_normalized_ strings are the product. Textkernel bills skills normalization and profession normalization as charges on top of base parsing, which tells you exactly where the value sits. ## The four kinds of vendor **Consolidated incumbents.** Textkernel acquired Sovren in November 2021, absorbing what had been the most widely embedded parser in the industry. The Tx Platform API is a `POST` to `/v9/parser/resume` carrying `DocumentAsBase64String` and a required `RevisionDate` so relative dates in the document resolve correctly. It returns a `ParsedDocument`, a `ScrubbedParsedDocument` with PII redacted, and `CreditsRemaining` on every single response. There is an optional `UseLLMParser` flag, which is the incumbents quietly admitting what changed in the last three years. RChilli sits in the same tier: 1,600+ recruiting platforms, a claimed 4.1 billion documents parsed per year, redaction across 57+ fields, and no published price. **Mid-market, self-serve-ish.** Affinda publishes numbers, which is rare enough to be worth naming: hosted from US$3,600 a year for 66,000 documents, self-hosted from US$12,000 a year for 500,000 documents. That is roughly 5.5 cents a document hosted and 2.4 cents self-hosted at the entry tier. There is a free browser tool that takes up to 100 documents at once with no signup, which is the fastest honest accuracy test available to you. HrFlow.ai sits nearby and exposes model tiers by latency, from a 500ms model to a 5 second one. **Commodity marketplace endpoints.** The APILayer listing is $0 for 100 requests a month, $29.99 for 1,500 and $49.99 for 4,500, and it is upfront that it is trained on a fixed inventory - 70,000+ skills, 26,000+ institutions - is English-first and gives “somewhat acceptable” results in a dozen other languages. For a prototype or a low-volume internal tool this is the correct answer and the enterprise quote is not. **Roll your own.** A modern LLM with structured output and a strict schema will parse a clean PDF resume competently. Where it still loses is the boring infrastructure: OCR on a photographed CV, 40-language coverage, deterministic date resolution, and a normalization taxonomy that maps “JS”, “Javascript” and “ES6” to one skill. Budget for those before assuming you have saved money. ## What the accuracy claims are worth Vendors advertise 95%+ and 96% accuracy. Those numbers are real in the sense that someone measured something, and useless in the sense that you cannot see the corpus, the field weighting or the scoring rule. Even Affinda’s own published breakdown shows the shape of the problem: contact fields land in the high nineties while work history sits around 87-88% and education around 85-90%. Headline accuracy is dominated by the easy fields. Test on your own corpus, on the fields your product actually depends on. If your matching logic keys on employer and dates, an extra point of email accuracy is worth nothing to you. ## The half nobody sells you Here is the structural gap. A parsed resume is a normalized description of one person. On its own it does nothing. Every downstream feature - matching, ranking, recommendations, market benchmarking - needs the other side of the join: a normalized corpus of live job postings. Parser vendors sell you one half and leave the schema mismatch as an exercise. This is measurable on our side. Across live postings in the JobsPipe index right now, 88.5% carry at least one normalized skill and 86.8% carry an ISCO-08 occupation code, with a median of 4 skills per posting. That is the surface a parsed resume has to land on. And it produces the finding that should change how you configure a parser. The most-demanded skills across live postings are not technologies: - communication - 2,127,911 live postings - leadership - 1,171,776 - compliance - 1,151,971 - attention-to-detail - 768,184 - customer-support - 735,615 - excel - 601,683 Narrow to software developers - ISCO-08 unit group 2512, the single largest occupation in the index - and it still holds. Communication appears in 101,369 of those postings, ahead of Python at 100,517, then CI/CD at 81,745, AWS at 69,906 and SQL at 59,881. A parser tuned to pull a technology list off a CV is optimizing for the fifth-most-common thing employers ask for. If your matcher only joins on tech keywords, it is scoring against a minority of the demand signal. ## Joining the two halves Once a resume is parsed, the query is straightforward. Take the extracted skills, map them to the taxonomy, and ask for live postings that want them: ``` curl -s -X POST https://api.jobspipe.dev/v1/jobs/search \ -H "Authorization: Bearer $JOBSPIPE_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "skills_or": ["python", "aws", "communication"], "occupation_code_or": ["2512"], "job_country_code_or": ["US"], "job_seniority_or": ["senior"], "posted_at_max_age_days": 7, "limit": 25 }' ``` Every posting comes back with `occupation_code` and `occupation_label`, `technology_slugs`, `esco_skills`, `normalized_title`, `seniority`, `company_domain` and salary in `min_annual_salary_usd` and `max_annual_salary_usd`. If your parser emits ESCO skill identifiers, skip the string mapping entirely and filter on `esco_skill_id_or`. The occupation code is the join that survives job-title chaos. ISCO-08 has 433 unit groups, and mapping both sides onto them means a resume reading “Full Stack Ninja” and a posting reading “Software Engineer II” meet in the same bucket. That is the same argument for using a taxonomy that we made in [the skills taxonomy guide](/blog/skills-taxonomy), and the mechanics of scoring after the join are in [how AI job matching actually works](/blog/ai-job-matching). ## What to actually build Pick the parser by volume and language need, not by the accuracy banner. Under a few thousand documents a month, a marketplace endpoint or an LLM with a strict schema is fine. Above that, or outside English, pay for a real vendor. Then spend the time you saved on the join: normalize both sides onto an occupation code and a skills taxonomy, and stop matching on raw strings. For the taxonomy itself, ESCO is free and well-documented - [the ESCO API guide](/blog/esco-api) covers access - and [ISCO-08](/blog/isco-08) is the occupation backbone underneath it. The job side is the part we run: 30+ ATS and job-board sources, normalized onto one schema, 1,000 jobs a month on the free tier. Match parsed resumes against live postings - normalized skills and ISCO-08 codes on every row. Free tier, API key in 30 seconds. [ ← Previous TalentNeuron review: what it sells, what the API meters, and who it is built for ](/blog/talentneuron-review)[ Next → JobsPipe for Slack: search live job postings without leaving the channel ](/blog/jobspipe-for-slack) --- Canonical URL: https://jobspipe.dev/blog/resume-parser-api Title: Resume parser API: the real options, and the half nobody sells you Description: Turning a PDF CV into structured JSON is a solved problem with four kinds of vendor behind it - consolidated incumbents like Textkernel, mid-market APIs like Affinda and HrFlow, commodity marketplace endpoints at $29.99 a month, and a roll-your-own LLM. Here is what each actually extracts, what the accuracy claims are worth, and the part every parser vendor leaves out: a parsed resume is useless without a normalized job corpus to match it against. --- AI agents: the full machine-readable index of this site is https://jobspipe.dev/llms.txt?src=md-twin - API quickstart, no-key sandbox (POST https://api.jobspipe.dev/v1/sandbox/jobs/search), MCP server, pricing. Free key: https://jobspipe.dev/signup