A recruitment website integration should follow the whole job lifecycle: publish an approved vacancy, update the same listing, close it correctly and reconcile the public set with the ATS. Displaying a feed once is insufficient when jobs change or a source becomes unavailable.
Keep public vacancy data separate from candidate records and application processing. Those flows can have different access, data and ownership requirements even when a visitor experiences them as one website journey.
Separate the public job feed from candidate data
Identify what the website is authorised to receive. A public vacancy feed may include a title, description, location and application route without granting access to CVs, interview notes or applicant status. Do not request broad ATS access merely because the website needs current job listings.
OneATS's public job integration guidance illustrates several publication approaches, including feeds, APIs and widgets. Check the actual ATS account and supported channel before choosing a method. Public documentation alone does not establish account eligibility or available features.
Decide where the application takes place. The website might link to an ATS-hosted form or provide an explicitly supported application integration. A link-based handoff has a different scope from collecting and transmitting candidate documents.
Assign public content ownership. Recruiters may approve the vacancy in the ATS, while the website team maintains presentation and navigation. Record which changes belong in which system so a local correction is not overwritten unexpectedly.
Map job identity and publication fields
Use a stable job identity to connect the source vacancy to its public listing. A changed title should not create a new unrelated page by accident. Equally, two separate vacancies with the same title should remain distinguishable.
Agree identity, mapping and reconciliation for ATS and website data exchange before implementing a feed.
Map fields according to their meanings. Employment type, location, remote-working description and application URL need agreed treatment. If the source omits information, define whether the listing can publish, requires review or excludes the field.
Indeed's XML feed guide demonstrates provider-specific job publication and field requirements. A website feed and a distribution partner feed may have different contracts. Do not assume one field mapping satisfies every destination or that a new integration has partner approval.
Plan rich-text handling and links in descriptions. The website should preserve useful structure through its supported rendering route without treating source markup as permission to run arbitrary content. Identify the allowed format and any transformations that affect meaning.
Define publish, update, close and reopen behaviour
Walk through a fictional job J101. Publication creates the intended public listing and valid application route. A later title change updates that listing under the same identity. Closure applies the agreed public behaviour rather than leaving an apparently open job indefinitely.
Choose what closure means on the website: removal from active lists, an unavailable message or another approved archive treatment. Include the application route and associated metadata in the decision. A closed job should not keep inviting applications through an overlooked secondary link.
Reopening needs a rule too. Decide whether the ATS represents it as the same vacancy or a new recruitment exercise and how the website reflects that identity. Avoid guessing based only on a similar title.
Record who may override a publication state and where. If the website hides a job locally while the ATS still marks it public, decide whether that is a supported exception or a discrepancy requiring correction at source.
Reconcile the website against the intended published set
A failed feed request differs from a valid response containing no open jobs. The integration should not interpret every unavailable source as an instruction to delete the entire public set.
Define the freshness and failure policy. The business may choose to retain the last known listings temporarily, flag uncertainty or restrict affected application routes. The correct response depends on the source contract and operational risk; it should be approved before the failure occurs.
Use this illustrative lifecycle checklist when reviewing the connection:
- Publish: one approved identity reaches the intended listing and application destination.
- Update: changed fields affect that listing without an unrelated duplicate.
- Close: public state, active lists and relevant metadata follow the closure rule.
- Feed failure: unavailable data is distinguished from an authorised empty set.
- Reconciliation: an owner can investigate missing, stale or unexpectedly public jobs.
Compare source and website sets using identities and relevant timestamps, then inspect differences. A matching total can conceal one missing job and one stale job. Keep operation references and failure evidence so the owner can resolve the actual case.
Initial imports and resynchronisation also need a boundary. Decide how jobs changed during the refresh are included and how partial responses are recognised. Do not present a partial page of source results as the complete intended publication set.
Review application routes and search metadata separately
Check the journey from a job page to the correct application destination. Include closed vacancies, changed ATS URLs and a source unavailable during navigation. A healthy listing page does not prove that its application route still works.
Review the public listing lifecycle alongside the relevant technical SEO checks for job pages.
Google's JobPosting documentation describes requirements and lifecycle considerations for structured job information. Metadata should correspond to the actual public vacancy and its state. Adding markup is not a guarantee of indexing or a particular search appearance.
Keep the responsibilities separate: public listing sync, application handling and search metadata can each succeed or fail independently. Acceptance should inspect each within the agreed integration boundary.
If an application form is part of the authorised scope, define its receipt separately from the job page. A visitor selecting “apply” does not establish that an application was accepted. Agree the confirmation reference, attachment status and recovery route for an interrupted submission. Keep candidate information out of public feed diagnostics, and assign any further data-handling decisions to the responsible team.
Review a bookmarked link to a closed job as well as navigation from the current vacancy list. Removing an item from a list does not explain what a returning visitor sees at its old URL.
Rehearse closure during a refresh using fictional job J101. The source marks it closed after the website starts reading a batch but before that batch finishes. Ask how the integration discovers the newer state and whether the next reconciliation identifies a stale listing. The answer should refer to the actual feed's snapshot, pagination or update contract. If the provider offers no consistent snapshot, keep that limitation visible and define the compensating review rather than promising an atomic copy of all vacancies.
Commission the integration around the job lifecycle
Prepare sample jobs covering publication, update, closure and reopening, using fictional or approved test data. Confirm the ATS access route and name the recruiter or operations owner who can judge the results.
The deliverable should be a maintainable publication process with visible failure handling. That makes current vacancies easier to manage without claiming that a successful feed pull proves every downstream job journey is correct.
Discuss publication ownership and failure handling for recruitment website integration with ZakCodeX.
