(Our work) · Sanctuary Graduates · JobAdder API
A jobs board, ready in days.
Sanctuary Graduates needed a production-ready replacement for an ATS-backed jobs board against a hard retirement date. We designed and built a branded .NET 10 experience around the JobAdder API, embedded it into the website they already had, and kept JobAdder as the one source of truth.
The public website already worked. JobAdder already owned the vacancies. The missing piece was the experience between them.
We left Sanctuary's Webflow site and JobAdder workflow where they belonged, then built the connecting layer: live search, job details, branded application journeys, employer logos and a responsive iframe that behaves like part of the page rather than a third-party portal.
(The brief)
The deadline was real.
The existing jobs board was scheduled to disappear at the weekend. Sanctuary did not need a holding page or a temporary redirect; candidates still needed to search, read and apply for live opportunities when the old service stopped.
That made the deadline part of the architecture. The build had to be fast without becoming disposable: proper OAuth2, server-side API calls, accessible forms, three distinct candidate journeys, resilient job data and an iframe integration that could be tested before cutover.
The result launched as a finished product, not an emergency placeholder — with the existing website, the ATS and the candidate experience working as one system.
What stayed. What changed.
| Kept | Built | Result | |
|---|---|---|---|
| The public website | Sanctuary's established Webflow site | A separate .NET 10 jobs application | No website rebuild and no duplicated navigation |
| Vacancy publishing | JobAdder as the system of record | A scheduled server-side advert synchronisation | Publish once in the ATS; the website follows |
| Role routing | A mandatory Job Type portal field | Graduate, Apprentice and Client Redirect journeys | The correct action and form every time |
| Applications | JobAdder's candidate workflow | Branded forms, screening answers and CV upload | Applications return securely to the ATS |
| Embedding | The existing jobs-board page | Origin-checked iframe resize and navigation messaging | One page and one scrollbar |
| Job data | A deliberately small live vacancy set | In-memory cache plus last-known-good JSON snapshot | No unnecessary SQL database |
| Employer branding | Sanctuary's client relationships and assets | A lightweight employer-logo uploader | Consistent cards without adding a CMS |
| Accessibility | The established Sanctuary brand | Keyboard-first forms, dark/light mode and accessibility controls | A WCAG 2.2 AA-oriented candidate journey |
| API resilience | JobAdder's live API and throttling rules | Safe OAuth refresh, request spacing and 429 handling | A small, supportable integration footprint |
One source of truth. One public experience. No second CMS.
(One board, three journeys)
The advert decides what happens next.
Sanctuary consultants select a mandatory Job Type when an advert is sent to the API portal. That single field gives the front end an explicit routing rule instead of making the website guess from a title or category.
Graduate roles use the full Sanctuary application, including university and degree information with a required CV. Apprentice roles use the school-leaver journey, with date of birth, region and highest qualification while keeping the CV optional. Client Redirect roles continue to the employer's own application page using a dedicated redirect-link field.
The same live JobAdder advert also supplies the title, description, salary, classifications, deadline, bullet-point highlights and screening questions. One advert drives the whole candidate journey.
See the live candidate experience(An honest question)
Why not use the ATS's hosted board?
Because the candidate experience matters. A hosted board could display vacancies quickly, but it would hand the design, search journey, application experience and accessibility detail to someone else's template.
The API route kept JobAdder in charge of the data while giving Sanctuary control of the public experience: their language, their role categories, their application rules, their accessibility controls and an interface that genuinely belongs inside the existing site.
Own the experience, keep the source.
(The support question)
What if JobAdder is unavailable?
Public search and job-detail requests do not wait for the ATS. The application synchronises the complete advert set in the background, swaps a thread-safe in-memory cache only after a successful complete read, and writes a last-known-good JSON snapshot to persistent storage.
That means a restart or brief API interruption does not empty the board. It also means there is no database to provision, back up or support for a tiny data set. OAuth credentials, refresh tokens and API calls remain server-side throughout.
Simple where it can be; careful where it has to be.
From cutover to production.
A hard retirement date, an existing Webflow site, JobAdder as the source of truth and three different application journeys. The scope was defined around what had to be live, not around adding another platform.
Working search, filters, cards, job details and role-specific application forms were designed together, then refined for mobile, keyboard use, dark/light mode and the existing site chrome.
OAuth2 authorization, portal fields, paginated advert reads, screening answers, CV upload, redirect links, source tracking, throttling and token refresh were connected and tested against representative roles.
CSP allow-lists and an origin-checked postMessage bridge let the child application resize inside Webflow, preserving one coherent page and one scrollbar.
The production subdomain, TLS, iframe routes and live ATS feed came together without rebuilding Sanctuary's website — delivering a proper replacement against the cutover date.
