How should a candidate CV reach your ATS?
A candidate CV-to-ATS workflow should receive an authorised document, extract relevant information, check for an existing candidate and validate the proposed changes before writing to the applicant tracking system. It should attach the source CV, preserve trusted information and route uncertainty to a named reviewer. TalentBraid can assess, build and manage this workflow where the source, parser and ATS provide suitable integration access.
The critical decision is whether a CV should create a candidate, update an existing record or wait for review. A new document does not necessarily mean a new candidate.
This guide explains that decision, the fields to map and the recovery controls to agree before launch. Bullhorn is used as a documented API example, not as evidence of a completed TalentBraid customer implementation.
CV parsing is one step in candidate intake
A resume parser converts document content into proposed structured data. Your agency still needs rules for identity, field ownership and the next action.
A candidate might submit an updated CV using a different email address. A recruiter might forward a CV already in the database. A document might omit a phone number that the agency has already confirmed. Each case needs a different response from an automatic new-candidate import.
Define the desired result before choosing the technology: a correctly linked candidate record, the relevant CV version, an accountable owner and a clear status for anything unresolved. Where the CV relates to a vacancy, preserve that application context separately from the person's identity.
Decide what can start the workflow
Start with one controlled intake route, such as a recruitment form submission, an approved mailbox folder or a designated upload area. Verify that the source exposes an approved API, webhook or export interface. Do not assume that every mailbox or file tool offers the same event coverage.
Create an intake item containing the source submission ID, attachment ID, received time, agency account, authorised uploader or channel, and known candidate or vacancy reference. Record those references outside the CV text. The document should not be able to assign its own owner or choose its destination record.
When webhooks are available, validate their documented authentication, durably queue the event and acknowledge it within the provider's deadline. Where polling is required, use a checkpoint and overlapping retrieval window, then deduplicate the results. Agree how historical documents and missed events will be reconciled.
Validate the file before extracting candidate data
Allow only the document types the agency has approved and the selected extraction route supports. Check size, actual file type and processing limits. Quarantine suspicious files, scan where appropriate and use controlled storage with restricted access. Do not rely on a filename extension or the sender's Content-Type alone. These recommendations align with the OWASP file-upload guidance.
An image-only PDF may need optical character recognition. A password-protected file, damaged document or unsupported format should enter an exception queue. A blank extraction is a processing failure to investigate, not evidence that the candidate has no experience.
Evaluate representative CVs before launch: different languages, layouts, long employment histories, scans, overlapping roles and documents exported from common editors. Confirm supported formats and any OCR requirement against the chosen parser and account.
If an AI model is used for extraction, treat all CV content as untrusted data. Text inside the CV must not alter system instructions, request external actions or override field permissions. Require a constrained output schema and source evidence for consequential values.
Match the candidate before creating a record
Use an existing authenticated candidate or application reference when the intake route provides one. Otherwise, evaluate permitted identity signals, such as email and telephone, against the ATS candidate records. Preserve the original values while applying documented comparison rules.
An exact email match is useful evidence, but it is not a universal identity guarantee. Shared addresses, outdated contact details and existing duplicates need handling. A name-only similarity should not authorise an automatic merge.
Use three explicit outcomes:
- Create: the agreed checks find no plausible existing candidate, required information is present and the creation policy permits the write.
- Update: the identity match is sufficient and proposed changes respect the agency's field rules.
- Review: multiple records are plausible, identity evidence conflicts or important information cannot be validated.
Candidate matching and file deduplication solve different problems. A file hash can detect the same bytes arriving twice; it cannot prove that two different CV files describe different people. Scope duplicate checks to the agency account, and retain the relationship between a candidate and each accepted CV version.
Map CV fields with explicit update rules
The following is a proposed field-mapping policy. The final fields, length limits, required values and relationships depend on the destination schema.
- Name: preserve spelling, diacritics and the original full name. Review uncertain splits rather than assuming every name has two parts.
- Email and telephone: validate format and distinguish candidate contact details from those of referees or recruiters. Review changes that conflict with verified contact information.
- Location: copy an explicit location only to the appropriate field. A CV address does not establish relocation preference or work authorisation.
- Employment history: retain employer, title and the stated date precision. Do not invent exact days from month-only dates or add overlapping roles together as if they were sequential.
- Education and certifications: distinguish completed, in-progress and unclear qualifications. Preserve evidence for the interpretation.
- Skills: map explicit skills to an agreed taxonomy. Record an unrecognised term for review rather than forcing it into the closest available category.
- CV attachment: retain the accepted source document, intake reference and version relationship according to the retention policy.
- Owner and source: derive these from the trusted intake route or agency assignment rules, not text inside the CV.
- Salary, notice period and availability: leave unchanged unless the workflow has suitable explicit evidence and the required approval. Absence from a CV does not mean a value has been withdrawn.
Agree a field-level precedence rule. For example, a recruiter-verified telephone number may remain authoritative until someone approves a change. A new upload time does not establish that every statement inside the document is more current than the existing record.
For existing candidates, show a proposed change set containing the current value, extracted value and source evidence. Avoid replacing the whole candidate object with parser output. Missing values should not silently clear trusted fields.
A Bullhorn CV-to-ATS API example
Bullhorn documents OAuth 2.0 authorisation followed by a REST login that supplies the session token and API base URL. Integration provisioning and the API user's permissions must be confirmed for the agency account. Use the returned base URL and manage credentials server-side. Bullhorn authentication guide.
The current API reference documents the following building blocks:
- POST /resume/parseToCandidateViaJson: parses supported text or HTML supplied as JSON into unsaved candidate-related data.
- GET /meta/Candidate: inspects the candidate schema and field requirements.
- PUT /entity/Candidate: creates a candidate after validation. POST /entity/Candidate/{id} updates an existing one.
- PUT /file/Candidate/{candidateId}: attaches a file. The reference also documents setting parsedResumeFile to the returned file ID for candidate file preview.
These are separate operations. Match the candidate before choosing create or update, and verify supported document conversion, required fields and permissions in the target account. Bullhorn REST API reference.
Bullhorn's resume-parsing walkthrough also describes creating education and work-history entities and linking skills. That illustrates why a successful parse does not prove the entire record is complete. Test each required object and association rather than treating the whole import as one write.
Keep an explicit state for candidate write, attachment upload and related-record completion. If an attachment fails after the candidate is created, resume from the saved candidate ID. Do not create another person simply to retry the attachment.
Put human review where it protects the record
Review should answer a specific question: which candidate is this, which change is supported, or which required value is missing?
Provide the reviewer with the source CV, the proposed destination, the current values and the precise reason the workflow paused. Separate low-risk formatting checks from identity conflicts or substantive profile changes. A single opaque confidence score is not an adequate explanation.
Bind approval to the document version, candidate ID and proposed changes. If another recruiter edits the record before the write, re-read it and check for conflicts. Do not overwrite a recent correction using an older approved proposal.
This workflow prepares records. It does not need to score suitability, reject candidates, infer protected characteristics or make employment decisions. Keep those activities outside scope unless separately assessed and explicitly designed.
Make retries safe and partial failures visible
Maintain a processing ledger keyed by agency account, source submission and attachment. Claim work atomically so repeated notifications or concurrent workers do not process the same intake item twice.
Store the resulting candidate and attachment IDs as each step completes. Use supported idempotency or external-reference mechanisms where available. A timeout after a write is an unknown outcome, so reconcile against the ATS before repeating the creation request. If the outcome cannot be determined safely, hold the item for investigation.
Use bounded retries for temporary connection failures, recoverable server errors and rate limits. Respect provider retry guidance and Retry-After where supplied. Invalid credentials, rejected field values and uncertain identity need an owner rather than indefinite retries.
Do not assume different APIs share a transaction. A candidate, CV attachment and employment-history record may succeed independently. Define which completed steps constitute an accepted intake and which partial states prevent the workflow from reporting success.
Keep error notifications concise. Include the intake reference and failure category, with a restricted link for investigation, rather than copying the entire CV into a chat message or log.
A hypothetical example: an updated CV arrives
A candidate sends a revised CV with a new email address and an additional role. The agency already has a record with a recruiter-confirmed phone number and notice period. The new CV omits both values.
The workflow detects a plausible existing candidate but cannot authorise the match from the changed email alone. It presents the evidence to the recruiter. After the recruiter confirms identity, the workflow prepares an update to the existing record, preserves the phone number and notice period, and attaches the revised CV under the agreed version policy.
A repeated delivery of the same intake item produces no additional candidate or attachment. If the attachment step fails, the exception refers to the existing candidate ID.
This is a proposed operating example, not a customer story or a measured TalentBraid result.
Measure useful records, not documents processed
Use the proportion of eligible CV submissions that produce a correctly matched, validated ATS record and required attachment within the agreed time window as the primary outcome. Define eligibility and sample records for accuracy; an API success response alone cannot confirm correct matching.
Track duplicate creations, manual correction rate, review backlog age, incomplete imports and recruiter handling time. Record why submissions were excluded so unsupported files do not disappear from the reporting denominator.
The agency operations lead should own the review policy and backlog. Recruiters should resolve candidate-specific uncertainty. The technical integration owner should investigate credentials, mapping failures, rate limits and missed intake events. Agree escalation paths and pause conditions before enabling automatic writes.
For the wider reporting implications, see what recruitment agencies can measure beyond standard ATS reports. The same record-quality principles also apply to our meeting-notes-to-ATS workflow.
Handle candidate data for a defined purpose
For EU-facing workflows, identify the lawful basis and explain the processing to candidates. Collect and transfer only the data required for the recruitment purpose. A submitted CV can contain sensitive details that should not become searchable ATS fields by default.
Define access, retention and deletion across intake storage, extraction services, queues, logs, backups and the ATS. Identify controller and processor roles, execute the relevant DPA, assess subprocessors and international transfers, and plan for correction and deletion requests. Consider whether a DPIA is required for the actual processing. These controls reflect GDPR requirements, including Articles 5, 6, 9, 13–14, 28, 32 and 35, and Chapter V. Official GDPR text.
TalentBraid supports GDPR-compliant workflow implementations. The controls must be checked for the specific engagement. Review our data-protection overview and DPA overview during scoping. If AI extraction is proposed, agree the provider, minimum payload, retention and processing region before enabling it.
When a managed CV-to-ATS workflow is useful
Begin by checking whether the ATS's existing import or parsing feature already meets the need. A custom connection becomes useful when the agency needs intake across approved channels, specific matching rules, controlled updates, review routing or technical ownership after launch.
TalentBraid builds and manages the automation layer for recruitment agencies. Dedicated engineers scope, implement, test and maintain the agreed workflow. Each engagement has a dedicated technical point of contact through an account manager or engineer according to scope.
For Bullhorn or an unlisted ATS, usable API access, webhooks or an approved integration interface allow us to assess the connection. Final compatibility depends on endpoints, permissions, authentication, limits, supplier terms and expected volume. Parsing, OCR or other third-party usage fees are scoped separately.
Book a call with us through TalentBraid, or email [support@talentbraid.com](mailto:support@talentbraid.com). Send your ATS name, where CVs arrive, the current manual steps, the desired outcome, expected volume and any available integration documentation. We will assess feasibility and a maintainable design before you commit.