Keep the ATS your consultants know
If your ATS does its job, a website project should start around it. Give employers a clear view of the agency and candidates accurate vacancies, then confirm which records and application routes your existing account can support.
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
Posting the same role twice and correcting it in two places is an admin task worth examining. We check whether your ATS can supply the website directly, how changes reach the public page and where a candidate's application goes. The account and vendor terms decide the connection we can actually build.
The feed or API
A vacancy feed or scoped API supplies the roles. We confirm which one your account exposes, who owns the authentication, and the rate limits, before promising anything.
Which record the team maintains
The ATS stays the source of truth for the vacancy. The website renders it and makes it readable. When the two disagree, the ATS wins and the page reflects that.
Where the application arrives
Whether an application completes on the website, in the ATS, or on a vendor-hosted route is a decision with real consequences. Write-back is only promised where the connector supports it.
What a vendor badge does and does not tell us
Spotting a recruitment platform in your markup tells us a family of software is present. It does not tell us your enabled features, your contract, your rate limits, or whether the specific operation you want is available on your plan. A sampled live role is evidence. A badge is a clue.
So we describe only what we can observe on a real role today, and we ask about the rest rather than inventing it.
Feed unavailable? Say so.
The demo jobs engine includes a stale feed and a failed adapter state with a retry, because feeds do fail and the board has to behave when they do. Pretending a feed is always healthy is how a board ends up advertising a role that was filled last month.
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.
Tell us your ATS and the operation you need
Name the system and what you want it to do with the public site. We will tell you what is feasible on your account, and what needs checking.