How we brought Workato's job discovery and detail pages into its own website without rebuilding the recruiting platform.

Your careers page needs to do more than list open roles.

It’s part of the brand experience, the candidate journey, the search experience, the analytics path, and the public content layer of the site. Yet a surprising number of companies treat it like a utility: a link to an external job board that happens to have their logo on it.

That isn’t necessarily wrong. An applicant tracking system (ATS) is supposed to manage recruiting, and for plenty of organizations its hosted job board is good enough.

But when the careers experience needs to behave like the rest of a serious corporate website, the question changes. How much of that experience should the website own, and how much should remain with the recruiting platform?

That was the challenge behind a recent Greenhouse integration we built for Workato.

The ATS was already doing its job

Workato wasn’t looking for a new recruiting platform. The jobs already lived in Greenhouse, and Greenhouse had the responsibilities you’d expect: the recruiting workflow, candidate applications, and the records the hiring team depends on.

The existing website could send visitors to Greenhouse-hosted job detail pages. That’s a normal arrangement. It gets candidates to the right place, and it avoids rebuilding a mature application system just to put a form on a branded website.

The problem wasn’t that Greenhouse was failing. It was that the website was giving away more of the candidate experience than it needed to.

A job search is still a search experience. A position is still a piece of public content. Candidates should be able to search, filter, navigate, and share a specific opening without feeling like they’ve left the website and started over somewhere else.

As soon as those things matter, an outbound link to the ATS stops being the complete solution.

Bring job discovery back into the website

The production implementation lived in Workato’s existing Contentful / Nuxt / TypeScript stack.

Rather than replacing Greenhouse, we brought the presentation and discovery layer into that environment. The careers site could now provide:

• Searchable job listings with meaningful filters.
• Multiselect filtering so candidates could narrow the results without starting over after each choice.
• Configurable metadata, instead of hardcoding assumptions about departments, job types, or other fields.
• Dedicated job detail views on Workato’s own URLs.
• Internal deep links to individual openings.
• Structured job data that could support search discovery.
• A clearer transition into the Greenhouse application flow.

Those sound like ordinary website features. That’s the point. A candidate browsing open roles shouldn’t need to know, or care, which system holds the recruiting records.

Decide who owns what

The most important part of this implementation wasn’t the search box or the filters. It was agreeing on where each responsibility belonged.

The website can present Greenhouse data without becoming another place where recruiting data has to be maintained.

That’s the part worth protecting. If a job closes, changes location, or gets updated in Greenhouse, the website shouldn’t become a second editorial system that needs someone to remember to make the same change.

This approach lets each system do the job it’s actually good at.

Job detail pages matter more than they seem

There’s a big difference between a list of jobs linking to another domain and a website that has its own page for each opening.

A first-party detail page gives a position an address within the company’s website. It can participate in navigation, be linked directly from campaigns or employee referrals, and fit into the same analytics and presentation model as the rest of the site.

It also gives the website a place to expose job-specific structured data alongside the information candidates can actually read. That matters for search. Markup such as JobPosting belongs on an individual job page, not on a general list of openings.

And because job openings are temporary, this introduces an operational requirement: the public page and its metadata need to reflect whether the position is still open. A polished job page that leads to a closed application is worse than a plain external link that works.

None of that means the website should take over applications. When candidates are ready to apply, Greenhouse is still the right destination. The goal is to make that handoff feel intentional rather than make the ATS disappear.

Start small to find the actual integration problems

One reason this implementation went in a productive direction is that we didn’t start by burying all the unknowns inside the production stack.

I had an older Greenhouse job board integration from a previous project. I recently rebuilt it as a small vanilla JavaScript prototype to test the fundamentals against the public Greenhouse Job Board API.

That prototype helped answer questions that sound trivial until you have to implement them:

• What does the API actually return for a job?
• Which metadata fields are present, and how consistent are they?
• How should multiple filters interact?
• What should a job detail URL look like?
• Which tracking information needs to survive the transition to the application?
• Where should the custom experience stop and Greenhouse take over?

With a working model, those questions became concrete. We could interact with the data and the interface before layering in the production application’s architecture.

The prototype wasn’t the production solution. It was a way to stop guessing about what the production solution needed to do.

Once we had that, the real implementation could live where it belonged: inside Workato’s existing Contentful, Nuxt, and TypeScript application, with its own conventions, design system, and operational requirements.

The right integration doesn’t replace the vendor

There’s a tendency in integration projects to think in extremes. Either accept the vendor’s default experience or rebuild the entire thing yourself.

Neither was necessary here.

Workato didn’t need to own the recruiting engine. It needed to own more of the experience surrounding it. Greenhouse didn’t need to become the website. It needed to keep doing the recruiting work it was already designed to do.

The production result was a careers experience with searchable listings, multiselect filters, first-party job details, deep links, structured data, and a controlled handoff to Greenhouse—all integrated into Workato’s own website.

That’s where the interesting integration work lives.

Not in replacing the vendor platform. Not in rebuilding the system of record. But in deciding which parts of the experience the website should reclaim, and which parts the platform should continue to own.

Explore Workato’s careers experience.