---
title: "Workable jobs sync settings"
description: "Subdomain, import schedule, JobPosting schema for Google for Jobs, sitemap, emails, filters and archives: every Workable jobs sync setting explained."
source: https://workable.w4dev.com/docs/settings/
---

Every setting below is on **Workable → Settings**. Each one is stored as the WordPress option
in the Option column, so WP-CLI can read it: `wp option get wkjb_apply_mode`.

## Workable account: connection and applications

| Setting | Option | Default | What it does |
|---|---|---|---|
| Account subdomain | `wkjb_subdomain` | empty | Required. Your Workable subdomain, such as `acme`. A full `apply.workable.com/acme/` or `acme.workable.com` address also works. A subdomain Workable does not recognise is not saved; the previous value stays. |
| API access token | `wkjb_access_token` | empty | Optional. Turns on on-site applications; needs the `r_jobs` and `w_candidates` scopes. Blank keeps the saved token; **Remove** deletes it. [How to create one](/docs/installation/#4-optional-add-a-workable-api-token). |
| Applications | `wkjb_apply_mode` | `auto` | Where candidates apply. See the next table. |

### Where candidates apply

| Mode | Value | With a token | Without a token |
|---|---|---|---|
| Automatic | `auto` | On-site form | **Apply on Workable** button |
| On-site application form | `form` | On-site form | **Apply on Workable** button |
| Send applicants to Workable | `redirect` | **Apply on Workable** button | **Apply on Workable** button |

The on-site form always needs a token, so **Automatic** and **On-site application form** behave
the same. Choose **Send applicants to Workable** to keep a saved token but use Workable's hosted
form.

Even with the form on, a job shows the **Apply on Workable** button when its form cannot be
loaded. See [when the token stops working](/docs/on-site-applications/#when-the-token-stops-working).

## Display: jobs address and import schedule

| Setting | Option | Default | What it does |
|---|---|---|---|
| Jobs page slug | `wkjb_jobs_page_slug` | `jobs` | The job list's address. With `jobs`, the list is at `/jobs/` and each job at `/jobs/{job-title}-{shortcode}/`, where the shortcode is Workable's 10-character job code. A change applies on the next page load. |
| Import interval | `wkjb_sync_interval` | `30` minutes | How often jobs are re-imported from Workable, from 15 to 1440 minutes. A change applies from the next scheduled run. |

There is no cache setting. Job lists and pages are read from your database. Each job's
application form is cached for one hour (developers: filter `wkjb_application_form_ttl`).

## Features: schema, sitemap and submissions log

| Setting | Option | Default | What it does |
|---|---|---|---|
| JSON-LD schema | `wkjb_enable_schema` | on | Adds `JobPosting` structured data to each job page, which Google for Jobs reads. |
| Jobs sitemap | `wkjb_enable_sitemap` | on | Lists job pages in the WordPress XML sitemap, at `/wp-sitemap-posts-wkjb_job-1.xml`, and each [job archive](/docs/job-archives/) in its own taxonomy sitemap. Turn it off to leave them all out. |
| Log submissions | `wkjb_log_submissions` | on | Keeps the last 100 application attempts under **Workable → Submissions**. [What each entry shows](/docs/on-site-applications/#the-submissions-log). |

The schema makes your job pages eligible for Google for Jobs. Workable's hosted job page may
carry `JobPosting` data for the same job, and Google chooses which listing to show.

## Schema: hiring organization and validity

These fill the `JobPosting` data when **JSON-LD schema** is on.

| Setting | Option | Default | What it does |
|---|---|---|---|
| Organization name | `wkjb_organization_name` | empty | The `hiringOrganization` name. Empty uses the company name from your Workable account. |
| Organization logo URL | `wkjb_organization_logo` | empty | Full URL of a logo image, added to `hiringOrganization`. Google for Jobs shows it next to your postings. |
| Job validity | `wkjb_job_validity_days` | `30` days | Sets `validThrough` to the posting date plus this many days, from 0 to 365. `0` leaves `validThrough` out, for roles open longer than a year. Jobs stay listed until they close in Workable either way. |

## Privacy: consent checkbox

| Setting | Option | Default | What it does |
|---|---|---|---|
| Consent checkbox | `wkjb_enable_gdpr` | off | Adds a required consent checkbox to the on-site application form. |
| Consent text | `wkjb_gdpr_text` | empty | The wording next to the checkbox. Links and basic formatting are allowed, so you can link your privacy policy. |

## Spam protection: Turnstile or reCAPTCHA

Configure one provider, or neither. With both blank, the form relies on its
[honeypot field and rate limit](/docs/on-site-applications/#what-happens-when-someone-applies).

| Setting | Option |
|---|---|
| Turnstile site key | `wkjb_turnstile_site` |
| Turnstile secret key | `wkjb_turnstile_secret` |
| reCAPTCHA site key | `wkjb_recaptcha_site` |
| reCAPTCHA secret key | `wkjb_recaptcha_secret` |

reCAPTCHA must be a **v3** key. Submissions scoring below 0.5 are rejected; the filter
`wkjb_recaptcha_score_threshold` changes that. Saved secret keys are never shown. Leave a secret
blank to keep the saved one.

## Application emails: hiring team and applicant

Both emails go out only after Workable accepts an application made on your site. Workable can
already notify your hiring team and acknowledge candidates, so turn these on only if it doesn't.

| Setting | Option | Default | What it does |
|---|---|---|---|
| Notify the hiring team | `wkjb_notify_admin` | off | Emails the job, the applicant's name, email and phone, and a link to the candidate in Workable. Reply goes to the applicant. |
| Notification recipients | `wkjb_notify_admin_to` | empty | Comma-separated addresses. Empty sends to the site admin email. Invalid addresses are removed on save, with a warning. |
| Confirm to the applicant | `wkjb_notify_applicant` | off | Emails the applicant a confirmation. |
| Confirmation subject | `wkjb_applicant_subject` | We received your application for {job_title} | One line of text. |
| Confirmation message | `wkjb_applicant_body` | A short thank-you signed with your site name | Plain text. |

The subject and message take the placeholders `{first_name}`, `{last_name}`, `{job_title}`,
`{job_url}` and `{site_name}`. Leave either blank to use the default.

Emails are plain text and never carry the resume or answers; those stay in Workable. A failed
email never fails the application. It shows as **Email failed** in
[the Submissions log](/docs/on-site-applications/#the-submissions-log).

## Job views: page view counter

| Setting | Option | Default | What it does |
|---|---|---|---|
| Count views | `wkjb_enable_view_tracking` | on | Counts views of each job page, shown in the **Views** column under **Workable → Jobs**. |

A small script counts the view after the page is shown, so it works on cached pages. It posts
to the REST route `/wp-json/wkjb/v1/job-view`.

- Each browser session counts once per job.
- Search engine crawlers, prefetches and logged-in editors are not counted.
- No IP address or cookie is stored. A hashed marker, kept for an hour, stops repeat counts.
- One IP address, or one IPv6 /64 network, adds at most 60 views an hour (filter `wkjb_view_rate_limit`). Behind a proxy
  that hides visitors' addresses, fix the address with the `wkjb_client_ip` filter or raise
  the limit.

## Job list: page size and filters

These apply to the jobs page, the [job archives](/docs/job-archives/), and any
[shortcode or block](/docs/shortcodes-and-blocks/) that does not set its own.

| Setting | Option | Default | What it does |
|---|---|---|---|
| Jobs per page | `wkjb_jobs_per_page` | `20` | Jobs per page, from 1 to 100. |
| Filters to show | `wkjb_filters` | Keyword search, Department, Location, Employment type, Workplace | The filters above the list. Function, industry, experience and education are also available. |

A dropdown with only one choice hides itself. Each option shows its total number of jobs, not
narrowed by the other filters. To keep a term out of every dropdown,
[hide it](/docs/job-archives/#manage-job-terms-in-wp-admin).

## Job archives: one list per department, location and type

Each slug gives a taxonomy its own job lists, one per term, under the jobs page slug. Leave a
slug blank to use that taxonomy only in the filter.
[How job archives work](/docs/job-archives/).

| Setting | Option | Default |
|---|---|---|
| Departments | `wkjb_tax_slug_department` | `department` |
| Locations | `wkjb_tax_slug_location` | `location` |
| Employment types | `wkjb_tax_slug_employment_type` | `type` |
| Workplaces | `wkjb_tax_slug_workplace` | empty |
| Job functions | `wkjb_tax_slug_function` | empty |
| Industries | `wkjb_tax_slug_industry` | empty |
| Experience levels | `wkjb_tax_slug_experience` | empty |
| Education levels | `wkjb_tax_slug_education` | empty |

A slug is refused, and the old one kept, when it is `page`, `feed` or `embed`, the jobs page
slug, or already used by another taxonomy.

## Tools: test, import and clear cache

At the bottom of the Settings screen:

- **Test connection** fetches your Workable job list and reports how many jobs came back.
- **Import jobs now** runs a full import straight away, and says so if one is already running.
  Below it, the panel shows the last import: when it ran and what changed, or **Last import
  failed** with the error.
- **Clear cache** deletes cached Workable responses, including application forms. Use it after
  you change a job's questions in Workable.

"Workable could not find that account or job (HTTP 404)" means the subdomain is wrong. Check it
against your careers page address.

## How the Workable jobs sync works

- Each import fetches your public Workable job list and compares it with the jobs on your site.
  New jobs are added, changed ones updated.
- Each job is a post of type `wkjb_job`, listed under **Workable → Jobs**. Jobs are managed in
  Workable, so there is no **Add New** button.
- Each import also files jobs under their department, location, employment type and five more
  [job taxonomies](/docs/job-archives/).
- A job that closes in Workable moves to the trash. If it reopens, its page comes back at the
  same address.
- If Workable cannot be reached or answers with an error, the import changes nothing. Your jobs
  stay up and the next run tries again.
- Imports run on WP-Cron, so on a site with very little traffic a run can start a little late.

## The Jobs screen

**Workable → Jobs** lists every imported job with these columns: **Workable ID** (linked to the
job in Workable), **Department**, **Location**, **Employment type**, **Posted**, **Views** and
**Applications**, the number accepted through your site. Sort by **Posted** or **Views**, and
filter by department, location, employment type or workplace.

Editing a job shows a read-only **Workable data** box: the fields Workable sent, the
application and view counts, and a **View on Workable** link. Workable is the source of truth,
so the next change there overwrites the job.