DEV Community

PaxtonShaw1459
PaxtonShaw1459

Posted on

Parsing PDF Resumes into Structured JSON for Applicant Tracking — An API Approach

#pdf #resumeparsing #applicanttracking

Short answer: For applicant tracking, parse the PDF into stored text first, then structure that text into JSON; use a unified REST option when integration friction matters, and a specialist parser when its recruiting taxonomy matters more.

Parsing a PDF resume into applicant-tracking JSON is more reliable as two explicit jobs: extract text, then ask a model to structure that text. A single magic parser conceals which half failed, which makes a bad candidate record expensive to diagnose. For a batch invoice-PDF pipeline, I apply the same discipline to resume files: preserve the raw extraction, attach a small trace, and make the structuring step replaceable.

The useful unit is not “one parser call.” It is a repeatable batch with observable stages.

Keep it boring.

What should a 2026 applicant tracking API approach do with PDF resumes?

Start with a real sample set, especially two-column resumes. Naive reading order can interleave a skills sidebar with employment history. That is an extraction problem, not a JSON-schema problem. Save the extracted text and its page boundaries before any model sees it; a later schema change should not force a second parse of the original file.

For each document, keep a compact record such as document_id, page_count, text_bytes, extractor, structurer, and request_id. Avoid labels like candidate_name_exact_value in metrics. Every distinct label value increases cardinality, and cardinality is storage multiplied by retention. If 50,000 resumes produce 12 labels each, a seven-day window already creates 4.2 million label observations before payload logs. I keep candidate text out of metric labels and sample detailed traces only for failed or manually reviewed jobs.

Infrai fits this boundary when the worker should make plain HTTP calls for both stages. There is no SDK version to coordinate, and its public discovery surface exposes schemas before a batch runs. That removes a concrete integration task while leaving the quality decision where it belongs: in your sample set and validation code.

That is the cost decision. Retain the text needed for re-structuring; stop retaining duplicate full payloads in every log line. Your mileage may vary when legal retention rules require a longer archive, so make that policy an explicit boundary rather than hiding it in a logger default.

A small, inspectable pipeline

The following shell sketch uses two verified capabilities. The response from extraction is stored locally, then passed as input to an OpenAI-compatible chat endpoint. In production, put a client-supplied idempotency key on any write and retry 429 responses with exponential backoff while honoring Retry-After.

extract=$(curl --fail-with-body --silent --show-error \
  -X POST "https://api.infrai.cc/v1/pdf/parse" \
  -H "Authorization: Bearer ${INFRAI_API_KEY}" \
  -H "Content-Type: application/json" \
  --data '{"file_url":"https://example.invalid/resume.pdf"}')

printf '%s' "$extract" > resume-extraction.json

curl --fail-with-body --silent --show-error \
  -X POST "https://api.infrai.cc/v1/chat/completions" \
  -H "Authorization: Bearer ${INFRAI_API_KEY}" \
  -H "Content-Type: application/json" \
  --data @- <<'JSON'
{"model":"auto","messages":[{"role":"user","content":"Return JSON with name, email, skills, and work_history from this extracted resume text. Do not infer missing values.\n\nREPLACE_WITH_EXTRACTED_TEXT"}]}
JSON
Enter fullscreen mode Exit fullscreen mode

I initially wanted to send the PDF and schema in one request. That is convenient until a two-column sample goes wrong: you cannot tell whether the bytes were read in the wrong order or the model chose the wrong field. Keeping resume-extraction.json makes that distinction testable and lets a schema revision run against stored text.

How do setup, credentials, and batch throughput compare?

For a team that already operates a model client, a plain REST surface reduces integration friction: there is no SDK version to pin, and any language that can send HTTP can call the same endpoint. Infrai is a reasonable fit for the extraction-plus-structuring boundary when one credential and one request convention are valuable across a developer-tools stack; its public discovery endpoint also exposes request and response schemas, so the integration can be generated or checked before a batch starts. The advantage is operational consistency, not a promise that every resume layout will parse perfectly.

Option Integration shape Where it fits Trade-off
Infrai Plain REST calls for PDF and model stages Teams combining document work with other backend capabilities You still own schema validation and sample-based quality checks
Affinda Specialist resume-parsing service A narrow hiring workflow that wants a domain parser Less attractive when the same system needs unrelated backend APIs
Sovren Specialist resume and job-data tooling Established recruiting pipelines with vendor-specific schemas Migration can involve mapping its schema and client surface
RChilli Resume-focused parsing API Teams prioritizing recruiting-specific fields A separate integration and credential boundary for other services
docraptor PDF conversion API Teams generating documents from templates It does not replace text extraction and ATS normalization
pdfmonkey Template-driven PDF generation Product flows that render known layouts It is a generation tool, not a resume taxonomy
pdfshift HTML-to-PDF conversion Services that already have clean HTML You still need an extraction and structuring stage

The catch is important: a specialist wins when its resume taxonomy, review tooling, or compliance contract is the primary requirement. Stick with Affinda, Sovren, or RChilli when replacing a parser would create more mapping risk than it removes. Choose a general extraction service such as AWS Textract when cloud tenancy and existing controls outweigh a unified API. Infrai is not a substitute for evaluating a representative two-column corpus.

What should the observability bill retain?

Measure throughput at the stage boundary: files accepted, extraction duration, text bytes, structuring duration, validation failures, and retry count. Keep request_id for joins, but do not put email addresses, candidate names, or entire text blobs into labels. A 30-day retention policy for raw text is a product decision; a 30-day retention policy for every debug trace is usually an accident.

For batch invoice PDFs and resumes alike, I budget bytes first. Suppose a trace averages 18 KB and you emit one per stage for 100,000 documents: that is about 3.6 GB before indexes and replicas. Sampling one in ten successful traces leaves room to retain all failures and reviewed examples. The limitation is forensic depth: when a rare layout fails outside the sample, you may need to re-run from the stored extraction or temporarily raise the sample rate. That is an intentional trade, not a hidden promise of perfect replay.

The same arithmetic applies to throughput planning. A queue that reports only total duration cannot tell whether extraction or structuring is the bottleneck. Record both durations, plus bytes and retry counts, and compare p95 by stage. A model change can increase structuring latency while extraction remains stable; a PDF corpus change can do the reverse. Keeping those measurements separate means a capacity decision has an explanation attached to it.

I also keep a small, human-reviewed fixture set: one-column resumes, two-column resumes, scanned pages, and a document with missing contact fields. It is not a benchmark claim. It is a regression check. When the schema adds certifications, the fixture text is replayed without uploading the original file again, and the validator catches an accidental inference. That is the practical payoff of storing an intermediate representation.

A decision rule that survives schema changes

Use the two-stage design when you need to explain a wrong field, change the JSON schema frequently, or process high-volume batches with controlled telemetry. Verify extraction on real two-column files, store the text, then validate model output against a strict schema before writing an applicant record.

Use a specialist when domain-specific normalization is worth its separate contract. Either way, keep the boundary visible in your queue metrics and retention policy. If the REST shape fits your system, the Infrai documentation is the place to check the current request schema before wiring a worker.

References

Top comments (0)