Customize the Job Posting Form

Control which fields appear on your board's job posting form — visibility, required status, and allowed options — for every posting surface on your board.

Job form settings control which fields appear on your board's posting form, whether they are optional or required, and which options are available to employers. The configuration applies to every posting surface on your board — your own operator form, the public submission form, and the employer forms.

Configure the job form

  1. Go to Board settings in the sidebar
  2. Click Job form
  3. For each field, toggle visibility using the Off / On / Required control
  4. To restrict the allowed options for a field, open the dropdown and select the values you want
  5. Click outside the dropdown to save

Changes are saved instantly. The public board's filter facets update to match; a facet reduced to one allowed option is hidden automatically. To rename field labels, use the Website builder on the Post a job page.

Fields

Each field is a separate card on the settings page:

  • Employment type: Limit the types available on the form. Selecting one removes the field and implies that type for every job.
  • Seniority: Show or hide the seniority field, mark it required, and restrict which levels are available.
  • Work arrangement: Limit accepted arrangements. Selecting one removes the field and implies that arrangement for every job.
  • Location: Restrict office locations to specific countries.
  • Salary: Show or hide the salary field, mark it required, set minimum and maximum bounds, and restrict accepted currencies.
  • Visa sponsorship: Show or hide the sponsorship question.

Custom fields

Beyond the built-in fields, you can add your own. Open the Custom fields section at the bottom of the Job form settings page and click Add field.

Each field has a label, a type, and an optional required toggle. Pick from six types:

  • Short text: a single line, for answers such as a security clearance.
  • Long text: a paragraph, for a longer description.
  • Dropdown (single choice): one value from a list of options you define.
  • Checkboxes (multiple choice): any number of values from a list you define.
  • Yes / No toggle: a simple flag.
  • Number: a numeric value, with optional minimum and maximum.

Drag the handle to reorder fields; the order you set is the order they appear on the form and the public job page. You can rename a field label or an option label at any time without losing answers already submitted. The field's internal key is fixed once you save, so stored answers stay linked.

Custom fields are captured on every posting surface (your operator form, the public submission form, and the employer forms) and validated the same way. Answers are shown on the public job page in an Additional details section, below the job description. The section heading and the Yes / No wording can be translated per board in the Website builder. Custom fields are display only for now: they do not feed search filters or structured data.

To remove a field, open its menu and choose Delete. You can keep submitted answers, which lets you re-adopt them later by re-creating a field with the same key, or delete them.

A board can have up to 20 custom fields, each select can have up to 50 options, and labels can be up to 60 characters.

Read the configuration via the API

Headless clients can read the board's job form configuration before rendering their own posting form.

text
GET /v1/settings/job-form

The endpoint returns the stored configuration object, or an empty object when no configuration has been saved. The object includes your custom field definitions (each with its key, label, type, and options), so a headless client can render them too. Authenticate with an API key, user session, or OAuth token. See the API reference for the full schema.

Write custom-field values via the API

Custom fields are display only on your board, but you can set their values through the Operator API. This is how an external enrichment workflow fills generated values onto jobs you have already imported.

Send a customFieldValues object, keyed by each field's key (from the configuration endpoint above), on either job endpoint:

text
POST /v1/jobs # set values when creating a job
PATCH /v1/jobs/{id} # add or change values on an existing job

On PATCH, writes are additive. A key you send is set or overwritten, and a key you do not send is left untouched, so you can enrich one field at a time without re-sending the whole bag. To clear a value, send it as null, an empty string, or an empty array. A false or 0 is kept as a real answer.

Values are validated against your definitions: the value must match the field's type, and a dropdown or checkbox value must be one of that field's option keys (not the option label). A wrong-typed value is rejected rather than silently dropped, and a required field cannot be cleared or left empty. Keys that are not defined on your board are ignored.

A typical enrichment round-trip, addressing the job by its id:

text
GET /v1/settings/job-form # learn the field keys, types, and options
GET /v1/jobs?externalId=REQ-123 # find the job, read its id from the result
PATCH /v1/jobs/{id} # write { "customFieldValues": { "clearance": "ts_sci" } }
GET /v1/jobs/{id} # read the values back

externalId is a lookup filter used to find the job; the value write is always addressed by the job's id. The same customFieldValues field is available through the CLI and the code-mode MCP, which inherit it from the API reference.

Frequently asked questions