Every ATS gives you a careers page. It sits on their domain, in their design, with their name somewhere near the bottom, and there is usually nothing you can do about that.
For a company that cares how it presents itself, that's an irritation. For an agency running hiring on behalf of clients, it's a real problem. The client wants their roles on their site, under their brand, not a link out to a tool their candidates have never heard of.
So: Vouch has a public API, and an apply flow you can embed anywhere.
Your jobs, on your own page
Two pieces that fit together.
The API serves your open positions, so you can render a job board on your own site: your design, your layout, your routing, your metadata. The embed handles the other end. One script tag drops a working apply or referral flow onto any page you own, so the candidate applies without ever leaving your domain, and the application lands in Vouch screened against your criteria like any other.
Between them you get a careers presence that's actually yours.
For agencies, this is the part worth reading twice. If you run careers pages on behalf of clients, each client's site can carry their own roles, in their own design, on their own domain, all fed from the one system you work in.
Your client gets a job board that looks like theirs. You never leave Vouch.
Catching candidates where you meet them
The same embed works anywhere you can put a page, which turns out to matter more than the job board.
A landing page for a campaign. A microsite for a graduate programme. A page behind a QR code on your stand at a career fair, so the people you actually spoke to end up in your talent pool that evening rather than as a stack of business cards you'll photograph in a fortnight.
Because Vouch already tracks where applicants come from, you can tell afterwards which event or campaign was worth doing again.
Keys and webhooks
You create API keys in the product, and you can narrow a key to specific positions. That's the difference between handing your website something that reads three published roles and handing it something that reads everything.
There are webhooks for the events worth knowing about: a position created or updated, a candidate added, moved, or hired. Each delivery is signed. The good uses are the boring ones: post new roles to a Slack channel, or push hires into your HR system so onboarding starts without someone remembering to trigger it.
The stance underneath this
We think an ATS should be a good citizen in a company's stack rather than the centre of it.
The reason to build this isn't that we expect most customers to write code against it. Most won't, and shouldn't have to. It's that if the answer to "can we put our own jobs on our own site" is no, the product has made a decision that wasn't its to make.
What's coming
This first version is read-only, and it's the start of a longer journey rather than the finished thing. Write access is next. Beyond that we're building toward an MCP server, so your own agents can work against your hiring data directly instead of you gluing it together by hand.
What we build first will follow what people actually try to do with it. If there's something you need, tell us, and it will shape the order.
Keys live under Settings → API + Webhooks, and the spec is served live from the API itself, so what you're reading is always what's deployed. The full release is on our changelog.