API Technical Specs
Once you have read the overview and understand the task at hand, follow these steps to get up and running. For a more in-depth explanation of parsing, read through the rest of the provided documentation.
1. Parse the sample doc
2. Save the results to disk
This step will allow you to verify that you are handling the encoding correctly when you receive results from our API. Save the parse results to disk in UTF-8 and open the file. If you see no corrupted characters/data, everything is working correctly.
3. Determine what data you want to parse for
By default, our parser will return everything it can except for military/security clearance, speaking engagements/patents/publications, and training.
It is a mistake to use speaking engagements/patents/publications data in any other capacity than simply a blob of text. This data is too unreliable/inaccurate for any other purpose.
Similarly, training data is extremely difficult to parse for. Our parser has no way of knowing every possible training course, so don't rely on complete training data to be parsed properly.
4. What data should you store?
You need to decide what data you will need to store for your application. Some customers store all of the data that the parser outputs, while others only need to store a small portion. A good starting point is:
- Contact Info
- Employment History
5. What data should you show?
Depending if you application is used by candidates, recruiters, or both, you will want to show different data to the end users. You need to decide what is important to the success or usability of your application. We have one recommendation here: it is a mistake to show a large number of skills or jobs.Just because the parser outputs all of the data from the resume does not mean the end user finds that information valuable. Most likely, the user only cares to see the most recent jobs and the top skills.
6. What should candidates be able to review?
If your application involves candidates uploading their own resumes, you might want to consider letting the candidate review the parsed data and make changes; however, we do not recommend letting candidates review the skills/taxonomies. Letting a candidate edit this data would make it easy for someone to "game the system". Data that should typically be reviewed by candidates is contact information and the most recent job. Never make candidate review everything. Consider business rules to limit data to be reviewed to a short subset of the overall data. As one example, limit data to the most recent three jobs, or all jobs in the last 5 years.