Keep the ATS your consultants know
Keep an ATS that works. We check how your account can supply live jobs and support applications through the website.
Identify the existing ATS, the available feed or API and which system owns each record.
Confirm access, fields, refresh behaviour and vendor constraints before agreeing the scope.
Translate supported vacancy facts into readable website pages, with a defined application destination.
Show where the application completes. Write-back is included only where the actual connector supports it.
Identify the existing ATS, the available feed or API and which system owns each record.
A proposed architecture, not a live vendor integration. Feeds, permissions, application handoff and write-back are confirmed for your specific connector.
Agree what moves between the desk and the website
Copying a role into two systems creates two places to correct it. We check whether your ATS can supply the website directly, within its account and vendor terms.
Where the ATS cannot support a task at all, a separate tool may be the honest answer. Those are described under recruitment software. The guide does the website need changing, or the ATS? is the check to run before replacing a system the consultants already use.
The feed or API
Confirm the available feed or API, account permissions, authentication and limits before agreeing a connection.
Which record the team maintains
The agreed source controls vacancy facts and status. The public page follows it.
Where the application arrives
Agree where applications complete. Writing back to the ATS depends on the connector’s supported operations.
What a vendor badge does and does not tell us
A platform badge identifies software, not your account’s features or permissions. We inspect a live role and confirm the actual connection.
Your account determines what we can build.
Feed unavailable? Say so.
Try a stale feed and a failed connection in the jobs demo. A useful board needs a recovery plan when its source stops responding.
See the feed states in the demoWhat we confirm before contract
- The supported feed or API, the authentication owner and the rate limits.
- What happens when the feed is unavailable or malformed.
- Where an application completes, and any applicant-data responsibilities that creates.
- Any third-party fees, because zero running cost is not a claim we make.
Connector logos, where used, are illustrative and never imply a partnership, a certification, or an implemented connector.
Questions owners ask
Connector feasibility, application handoff, and why the ATS stays in charge of the vacancy record.
Can you connect to our ATS?
We check the feed or API, account permissions and limits before agreeing a connection. A vendor badge does not tell us what your account can do.
Does the ATS stay the source of truth?
Yes. The agreed source controls vacancy facts and status. The public page follows it.
Where do applications complete?
We agree that before contract. Writing back to the ATS depends on the connector’s supported operations.
What data do you handle?
Candidate information stays subject to its privacy and access requirements. Applicant-data responsibilities are confirmed when we agree the application route.
What if the feed fails?
A useful board needs a recovery plan when its source stops responding. We confirm that behaviour, and any third-party fees, before contract.
Tell us your ATS and the operation you need
Tell us your ATS and the task you want it to support.