CV parser API: the options, what each returns, and what it costs
Published
A CV parser API takes a resume file — PDF, DOCX, an image of a printed page — and hands back structured fields: name, contact details, employers, job titles, start and end dates, education, skills. The choice in front of you is smaller than the search results suggest. There are purpose-built HR parsing vendors that sell by credit and expect a contract, general document-AI platforms that parse a CV as one of a hundred document types, open-source libraries you host yourself, and a small number of plain per-call APIs. They differ far more in how they bill and what shape the output takes than in whether they can read a PDF.
We build ResumeJSON, one of the plain per-call options, so read this as written by an interested party. Every figure below about another vendor was read from that vendor's own pricing page in September 2026, and those pages are theirs to change — check anything you are about to sign.
The short verdict
| If this is you | Pick |
|---|---|
| You want one HTTP call, typed JSON back, no contract | A per-call parsing API |
| You parse both CVs and job postings, and need taxonomy normalisation | An HR parsing vendor (Textkernel, RChilli) |
| CVs are one of several document types you process | A document-AI platform (Affinda, SharpAPI) |
| Volume is high, data must never leave your network | Host an open-source parser |
| You need text, not fields | A document converter, not a parser |
What a CV parser API actually has to return
This is the line that decides most of the choice, and it is easy to miss when every product page says "parse".
- Text extraction gives you the words on the page, in reading order. A dozen free libraries do this well.
- Field extraction decides that this line is an employer, that one is a title, and that a role with no end date is the current one. That is the part you are paying for.
If you only need the first, you do not need a CV parser API at all — see our Docling alternative piece for where that boundary falls, and open source resume parser for what the free libraries manage on the second.
A parser that returns a flat bag of strings is not the same product as one that returns a typed object. Ask for a sample response before you compare prices: the amount of code you write after the call is the real cost difference between two vendors quoting the same figure.
The HR parsing vendors
These are the incumbents in recruitment. They parse CVs and job postings, normalise skills and job titles against a taxonomy, and sell in credit blocks.
RChilli publishes a credit-based price list. Its page offers 100 credits free to start, and a starter position of "3,000 credits for as little as $150", noting that the subscription then renews at "$75 monthly for 500 credits" once the startup plan expires. Larger volumes are a slider and, past it, a quote. We have a fuller head-to-head on our RChilli alternative page.
Textkernel (which absorbed Sovren) also sells parsing by credit, with one credit parsing one resume and add-ons such as skills normalisation and OCR billed on top. The current plan table is in our Textkernel pricing article, and the Sovren question — where Sovren pricing went — is answered in the same place.
These vendors are worth their price when you need the taxonomy. Normalising ten thousand ways of writing "Senior Software Engineer" into one code is genuinely hard, and it is not something a per-call parsing API does for you.
The document-AI platforms
These parse anything: invoices, bank statements, passports, and CVs as one document type among them.
SharpAPI prices by credit-month rather than by document. As of September 2026 its published tiers are:
| Plan | Price | Words per credit (monthly) | Words per credit (yearly) |
|---|---|---|---|
| Build | $50 /credit/month | Up to 250k | Up to 3 million |
| Launch | $200 /credit/month | Up to 1.6 million | Up to 20 million |
| Scale | $500 /credit/month | Up to 5 million | Up to 60 million |
Its own explanation is that "your total monthly cost is simply per-credit price × number of credits", and that annual billing "includes an additional 20% discount + 12x word quota per credit". The Build tier lists 100 API requests per minute.
Affinda sells a configurable document-AI platform with a resume parser among its document types; our Affinda alternative page covers where that fits and where it does not.
The trade with a platform is the same in both cases: you get one vendor for every document your product touches, and you pay in a unit — words, credits, workspace seats — that does not map cleanly onto "one CV parsed".
The per-call APIs
The smallest shape: one endpoint, one key, a price per parse.
ResumeJSON is this shape. You POST a PDF, a DOCX, plain text, or a photo or scan of a page, and get back a typed JSON resume. Plans are sold through RapidAPI, and the published table on our pricing and quickstart page reads:
| Plan | Price | Included |
|---|---|---|
| Basic | $0 | 100 parses a month, a hard cap that can never bill you |
| Pro | $0 | Pay per use — $0.05 a parse, no monthly fee |
| Ultra | $29 | 1,000 parses a month, then $0.045 a parse |
| Mega | $99 | 5,000 parses a month, then $0.018 a parse |
You can check the output before any of that with the free parser, which needs no signup, and the field reference is the full list of what comes back.
When you should not buy a CV parser API at all
- The documents cannot leave your network. A contract or a regulator that fixes where processing happens rules out most hosted APIs. Host a parser, or buy from a vendor that documents a self-hosted install.
- Volume is enormous and the fields you need are few. If all you want is an email address and a phone number from a million files, a regex over extracted text is cheaper than any API.
- You need text, not fields. A converter is the right tool and most of them are free.
- You are building a resume, not reading one. The JSON Resume schema is what you want, and nothing needs parsing.
- You already run Python or PHP and the CVs are uniform. Our Python resume parser and resume parser PHP walkthroughs have working code; for skills specifically, extract skills from a resume.
How to compare two of them honestly
- Parse the same ten CVs through both. Use your own worst files — a two-column design, a scan, a CV in a second language — not the vendor's sample.
- Diff the JSON, not the marketing. Count the fields you would otherwise have written code to derive. A vendor that returns a current-role flag has saved you a date comparison you would get wrong on the edge cases.
- Price the month you expect, not the month they quote. Credit-block pricing and per-parse pricing cross over somewhere; find where, for your volume, before you commit. A month with no hiring costs nothing on pay-per-use and a full block on a subscription.
- Check what a failure looks like. A parser that returns a confident half-empty object on a file it could not read is worse than one that returns an error, because nothing downstream notices.
How to switch from one to another
The migration is usually three changes, and none of them are large:
- Swap the call. Every one of these is an HTTP POST with a key header; the differences are the header name and whether the file goes as Base64, multipart or raw bytes.
- Write a mapper, not a rewrite. Map the new response onto the shape your application already uses. Keep it in one file so the next comparison costs you that file and nothing else.
- Run both for a week. Send each CV to the old and the new parser, store both, and diff. A week of double-parsing is cheap next to a field that was silently empty for a month.
If you want a side-by-side of the wider category rather than the API shape, our resume parsing software comparison covers it.
The honest summary
There is no CV parser API that is the right answer for everybody. If you need taxonomy normalisation and job-posting parsing, an HR vendor earns its credit price. If CVs are one of many document types, a platform is one integration instead of five. If you want a PDF in and typed JSON out with no contract, a per-call API is the smaller thing, and that is the one we build. What you should not do is pick on a published price alone: the shape of the response decides how much code you write afterwards, and that is nearly always the bigger number.