ResumeParser.pro

Every Field a Resume Parser Extracts

The complete field inventory of a production resume parser — real schema field names, grouped by cluster, with the derived signals most people don't know parsing can produce.

A production resume parser extracts 50+ fields: identity and contact data, per-role work history with skills, education with normalized degrees, certifications, languages, projects, publications, licenses, plus derived signals like years of experience and management level. The tables below list the actual SharpAPI schema.

Identity, contact and profiles

Candidate profile · scalar fields
FieldContents
candidate_nameFull name as written
candidate_emailEmail address
candidate_phonePhone number(s)
candidate_address / _city / _countryLocation; country as ISO 3166 name
candidate_linkedin / _github / _twitter / _websiteProfile and portfolio links
candidate_date_of_birth / _nationalityPresent on many EU CVs; your platform decides whether to store them
candidate_language / candidate_spoken_languagesDocument language and declared spoken languages
candidate_summary_objectiveThe candidate's own summary statement

Work history — the array that matters most

Each entry in positions[] is one role with its own dated context, including up to 25 skills attached to the position where they were used rather than a single undated skill cloud:

positions[] · one object per role
FieldContents
position_name / company_name / countryRole, employer, location
start_date / end_dateYYYY-MM-DD; null end date = current role
skills[]Up to 25 skills used in this specific role
job_detailsThe role description text

Education, with normalized vocabularies

education_qualifications[] normalizes the world's degree systems into comparable values — school_type (University, Polytechnic, College, High School, Professional training — each “or equivalent”), degree_type (Doctorate, Master's, Bachelor's, Diploma, High School Diploma, Professional Certificate) and learning_mode (in-person, online, hybrid, trainee programme), alongside school name, faculty, specialization, country and dates.

Qualifications and extras

  • candidate_courses_and_certifications[] — courses, certificates, professional qualifications
  • candidate_honors_and_awards[] — distinctions and awards
  • projects[] — name, description, URL per project
  • publications[] — title, publisher, date, URL
  • volunteer_experience[] — role, organization, dates, details
  • references[] — name, position, company, contact
  • drivers_licenses[] — license categories
  • interests_hobbies[] — as declared

Derived signals — computed, not copied

The most useful fields for ranking are the ones no resume states outright. The parser computes them from the document's evidence:

Derived fields · computed from evidence
FieldValues
years_of_experienceTotal professional years, computed from position dates
has_management_experience / management_levelnone · team_lead · manager · director_or_above
has_remote_work_experience / remote_work_typenone · hybrid · fully_remote
work_authorizationWork-permit status where the document states it
brief_summaryA generated summary of the candidate
approximate_ageEstimated from graduation and career dates, and stripped before any match scoring

The guarantee that makes the list usable

Every field above returns on every parse: empty when the document lacks it, never missing. That determinism is what lets you write integration code against the sample payload once and run it on a million documents. To see the fields filled with real data, the explorer on that page shows a complete unedited response.

Questions, answered

How many fields does a resume parser extract?

Production parsers return 50+ fields. SharpAPI's schema spans contact data, work history with per-role skills, education, certifications, languages, projects, publications, volunteer work, licenses and derived signals like years of experience and management level.

Can a parser extract skills per job, not just one list?

Yes — the SharpAPI schema attaches up to 25 skills to each position, so you can see what a candidate used at which job and when, rather than one undated skill cloud.

What derived fields can parsing produce?

Beyond literal extraction: years_of_experience, has_management_experience with a level, has_remote_work_experience with a type, work_authorization and a brief summary — signals computed from the document's evidence.

What happens to fields the resume does not contain?

In a deterministic schema they return empty — an empty string or array, never a missing key. Your code reads the same structure for every document.