Resume Parsing API: When You Need a Parser and When You Need a Pipeline

You are adding CV upload to a product. A job board, an ATS, an HR platform, a marketplace where freelancers create profiles.

So you look at resume parsing APIs. Affinda, RChilli, Textkernel, Sovren, Daxtra. All good, all mature, all quoting field counts and accuracy percentages at each other.

And most of them are selling something slightly different from what you need.

01Two Different Purchases

Buying a parsing product. Resume parsing is your business, or close to it. You need 200 fields, a skills taxonomy, semantic matching, cross-lingual normalisation, and an enterprise contract. Textkernel, Sovren and Daxtra are built for this and they are genuinely excellent at it.

Buying a parsing step. You are building something else and CV upload is one feature of it. You need names, employers, dates and skills as structured data, and then you need to get on with the rest of your product.

Both are legitimate. The pricing tells you which one a vendor is selling: RChilli from $75 a month, Textkernel from $99, Affinda from $800 a year, Daxtra on request. Those are product prices, and they are correct if parsing is the product.

If parsing is a feature, you are paying a platform price for one call.

02A CV Upload Feature Is Not One Step

Here is what actually ships when you build "upload your CV to apply".

1. Accept the file. Whatever the candidate has. PDF from Word, DOCX, an RTF from 2011, a photo of a printed CV taken on a phone.

2. Handle the scanned ones. A photographed or scanned CV has no text layer. Without OCR it parses to nothing, and this is more common than people expect, particularly outside Western Europe and North America.

Worth knowing what OCR does badly before you rely on it. We tested Tesseract on a clean machine-rendered invoice in OCR in Python and it dropped the decimal point in four of seven monetary values, at 93 to 96% reported confidence. Multi-column CVs break the same way, for the same reason.

3. Parse it. The step everyone shops for.

4. Validate what came out. This is the one nobody plans for. A parser returns the email address it found on the page. It does not tell you whether that inbox exists. Typos in CVs are extremely common, and an unreachable email means a candidate you cannot contact, sitting in your database looking fine.

5. Check the phone number. Same problem. Wrong country code, missing digits, a landline where you expected mobile.

6. Handle language. A CV in Dutch, German or Arabic parses, but your reviewers may need it in English.

7. Do something with the result. Deduplicate against existing candidates, score against a role, suggest related skills, index for search.

8. Store it, lawfully. Candidate CVs are personal data under GDPR. Where it is processed, how long it is retained, and who the sub-processors are all matter, and someone will eventually ask you in writing.

Parsing is step three. A parsing vendor sells you step three. Steps two, four, five and six are other vendors, other keys, other bills, other compliance reviews.

03What You Should Actually Look For

Ignore the field-count arms race for a moment. Four things decide whether a parser works in a product.

Does it handle scanned CVs? If OCR is a separate product or a separate fee, that is a second integration for a common case.

How many languages? Not a vanity metric. If you recruit across Europe you will receive CVs in six languages in the first month. Affinda states 50+, RChilli 40+, Textkernel 29.

Is it async, and does it webhook? Parsing takes seconds, not milliseconds. A synchronous API blocks a request thread. Polling works; a webhook is better for bulk.

What is the compliance posture? Transient processing, no training on your data, and a named certification. You will be asked.

Field count matters far less than vendors imply. Most products use eight to twelve fields. The 200-field parsers are selling to companies whose product is the parsing.

04The Parser in the ApyHub Catalog

The Resume Parser API, published by SharpAPI, covers all four:

80+ languages, including mixed-language documents, with optional output normalisation. That is more than Affinda, RChilli or Textkernel state.

OCR included. PDF, DOC, DOCX, TXT and RTF, plus JPG, PNG and TIFF. Scanned and photographed CVs are OCR-processed before extraction, in the same call. No separate OCR vendor, no extra fee.

Async by design. POST the file, get a job_id and a status URL, poll until the status reaches success. Webhooks are available as an alternative to polling for bulk pipelines.

45+ fields in a consistent schema regardless of layout or language. Candidate details, work history with employers, roles, dates, countries and per-position skills, education with degree types and institutions, plus years_of_experience, brief_summary, projects, volunteer_experience, publications and references.

SOC 2 Type II and GDPR, with candidate data processed transiently and never used for model training.

But parsing is step three. The reason to look here rather than at a parsing vendor is what covers steps two, four, five and six.

05The Rest of the Pipeline, Same Key

Step by step, with what covers it

The HR set from one provider

SharpAPI publishes 26 endpoints in the catalog. The HR ones form most of a hiring pipeline.

Matching and scoring

• Resume/CV Job Match Score scores a parsed CV against a job description across a dozen dimensions. For most ATS and job board products this is the step straight after parsing, and it normally means a second vendor.

Making candidate data searchable

• Related Skills Generator expands what the parser found. A candidate listing React probably knows JavaScript.
• Skills Database is the queryable taxonomy behind it.
• Job Positions and Related Job Positions Generator normalise titles, so "Senior Frontend Dev" and "Front-End Engineer II" land in the same bucket.

The other side of a marketplace

• Job Description Generator if you also post roles.
• Global Salary Benchmark for offer guidance and flagging outliers.

Cleaning up free text

• Detect Email Address and Detect Phones Numbers pull contact details out of summary fields the parser left as prose.
• Detect Spam for anything candidate-submitted.
• Proofread and Grammar Check if you offer CV feedback as a feature.
• Summarize and Paraphrase for reviewer-facing output.

From the wider catalog

Verify the contact details. Advanced Email Verification checks whether the address accepts mail, not just whether it looks valid. Disposable Email Checker flags throwaway domains. Email MX Lookup confirms the domain runs a mail server at all.

This is the highest-value addition to a CV pipeline and almost nobody builds it. A parsed CV with an unreachable email is a candidate you have lost without knowing.

Normalise the file. File conversion handles anything the parser will not take. Document extraction covers the cases where structure matters more than text, which is the same problem we wrote about in PDF-to-Excel.

Check the employers exist. Domain age and WHOIS lookups on the companies a candidate lists. Registration date is the cheapest check available, covered in Domain Intelligence APIs.

One key. One bill. One compliance review.

Try the Resume Parser API | Get a free API key

06Three Rules for Building the Pipeline

Run independent checks in parallel. Email verification and phone validation have nothing to do with each other. Running them in sequence doubles the wait for no reason.

Make expensive steps conditional. Only translate when the parsed candidate_language is not one your reviewers read. Only score against a role for candidates who cleared validation, so you never score a CV you cannot contact.

Order by cost, cheapest first. Put the decisive cheap checks before the expensive ones. If email verification rejects a candidate, nothing after it needs to run.

One structural note: parsing is asynchronous and most of the other steps are synchronous. Mixing both patterns in one flow is the most common source of integration bugs, and it is worth planning for rather than discovering. API Chaining in 2026 covers sequencing and partial failure.

07When to Use a Specialist Instead

Being straight about this, because sometimes the answer is a parsing vendor.

Your product is parsing or matching. If you sell an ATS, a matching engine, or a talent intelligence platform, parsing quality is your product quality. Buy the best one and negotiate an enterprise contract.

You need a skills taxonomy. Matching Softwareentwickler to Software Developer across languages is a research problem, not a field. Textkernel and Sovren have invested years in it.

You need on-premise or VPC deployment. Some staffing and government contracts require it. Daxtra and Sovren support it.

You need 100+ fields. If your data model genuinely uses them, use a parser built for it.

You need contractual accuracy guarantees. Enterprise vendors will negotiate them. Note that most published accuracy figures are self-reported, and independent testing is limited, so test on your own documents either way.

If none of those apply, you are building a feature, and a feature does not need a platform contract.

08Test It on Ugly Documents

Whichever you choose, this is the step that decides the outcome.

Do not test on a clean, well-structured CV. Every parser handles those. Test on:

• A two-column creative CV, where reading order breaks
• A photographed or scanned document with no text layer
• A CV in a language you do not read
• A ten-year career with gaps and overlapping roles
• A CV with tables for skills

Published accuracy figures come from vendors and cluster around structured, English-language documents. Accuracy drops on creative layouts, multi-column designs, scanned PDFs and non-English files, which is precisely the set your users will upload.

Every service page has a playground, so you can upload your three worst CVs and read the actual output before writing any code.

09Conclusion

The resume parsing market sells parsing products, and the comparison articles rank them on field counts and accuracy claims.

If parsing is your product, that comparison is the right one and you should read it carefully.

If parsing is one step inside something else you are building, the useful question is different: what does the whole CV intake flow need, and how many vendors will you be managing by the end of it.

Parsing is step three of eight. Buy the step, not the platform.

Browse the AI catalog | Start free, no card

10FAQ

What is a resume parsing API?

An API that takes a CV file and returns structured data: candidate details, work history, education and skills as JSON. It replaces manual data entry when candidates upload documents, and it is the core of any CV upload feature.

How does resume parsing work?

You upload a file, the service extracts text (running OCR first if the document is scanned), then a model identifies which text belongs to which field and returns a consistent schema. Good parsers return the same structure regardless of the CV layout or language.

Can a resume parser read scanned or photographed CVs?

Only if OCR is included. A scanned document has no text layer, so a parser without OCR returns nothing. The Resume Parser API in the ApyHub catalog accepts JPG, PNG and TIFF alongside document formats and OCR-processes them in the same call.

How many languages can a resume parser handle?

It varies widely and it is worth checking. Affinda states 50+, RChilli 40+, Textkernel 29. The parser in the ApyHub catalog handles 80+ languages including mixed-language documents.

Is resume parsing synchronous or asynchronous?

Almost always asynchronous, because parsing takes seconds rather than milliseconds. You submit the file, receive a job ID, then poll a status endpoint or register a webhook. Building for a synchronous response is a common early mistake.

What fields does a resume parser extract?

Typically candidate details, work history with employers, roles, dates and skills, and education with institutions and degrees. Better parsers add derived fields like years of experience, a summary, projects, publications and volunteer experience. Most products use eight to twelve of them.

Should I validate the email address a parser extracts?

Yes, and most teams do not. A parser returns the address it found on the page. It cannot tell you whether the inbox exists, and typos in CVs are common. An unreachable email is a candidate you have lost without knowing it, so pair parsing with email verification.

Is resume parsing GDPR compliant?

It depends on the provider, and CVs are personal data so this matters. Look for transient processing, an explicit commitment not to train on your data, a stated retention period, and a named certification. The parser in the ApyHub catalog is SOC 2 Type II certified with GDPR-aligned handling.

How accurate are resume parsing APIs?

Vendors publish figures between 95% and 99%, almost all self-reported, with limited independent testing. Accuracy drops on creative layouts, multi-column designs, scanned documents and non-English CVs. Test on your own worst documents rather than trusting a headline number.

Should I build resume parsing myself?

Rarely. Extracting reliable structure from arbitrary CV layouts in dozens of languages is a genuinely hard problem, and it is not the problem your product exists to solve. The build-versus-buy question here is not whether to use a parser, but whether you need a parsing platform or a parsing step.

11Further Reading

• API Chaining in 2026 - sequencing a multi-step pipeline without it breaking
• OCR in Python - what goes wrong when a document has no text layer
• Domain Intelligence APIs - verifying that the employers on a CV exist
• The Hard Part of PDF-to-Excel Isn't the Text, It's the Table - the same structural problem in a different format
• Browse the HR catalog - resume parsing, job matching, skills data and salary benchmarks

12About ApyHub

ApyHub is a curated API catalog for developers, teams, and AI agents. The HR category covers resume parsing, ATS optimisation, salary benchmarking and skills data, alongside data validation, AI and OCR, file conversion and more across 20 categories.

One subscription covers the whole catalog, billed in atoms, with headroom pooled across every API rather than locked to individual services. Every service carries machine-readable certification covering data handling, retention, and standards alignment including GDPR, SOC 2, and ISO 27001. Every endpoint is MCP-ready by default.

ApyHub is headquartered in Amsterdam, with offices in the Netherlands, Greece, and India, and runs on EU infrastructure. The catalog holds 450+ services and 1,500+ endpoints, with new APIs and providers onboarded continuously. The free tier allows 5 calls a day with no credit card, and every service page has a playground for testing before you build.