Filter reference

One filter object is used in three places: search_jobs takes it as filters, save_search takes it as prefilter, and check_prefilter validates one and tells you how many postings it would catch. This page is that language. There are 48 fields.

A field name that is not in the catalogue is refused, not quietly ignored — so a typo fails loudly rather than widening your filter. Read Conventions before writing your first one: three of them are not guessable and all three produce a refusal you cannot explain from the field alone.

The five value shapes

Each field has a type, and the type decides the envelope its value takes. Text is the odd one out and worth reading twice: the operator IS the key, and there is no operator field at all.

{
  "<field>": {
    "all_words": "python scraper",
    "none_words": "wordpress"
  }
}

{
  "<field>": {
    "operator": "greater_than",
    "value1": "1000"
  }
}

{
  "<field>": {
    "operator": "equals",
    "values": [
      "<one of options>"
    ]
  }
}

{
  "<field>": {
    "value": "Yes"
  }
}

{
  "<field>": {
    "operator": "after",
    "date1": "2026-01-01"
  }
}

Conventions

Three rules that no single field entry could tell you, and that produce refusals which make no sense until you know them.

• type names — textnumericselectbooleandate
• numbers are strings — numeric values go in as STRINGS — value1: "1000", not 1000. This is the v1 filter format the saved-search engine reads, and a real number is refused.
• booleans are yes no — boolean values are the strings "Yes" and "No", not true and false, for the same reason.
• options are authoritative — where a field carries `options`, that list is what the validator accepts. A field's prose `description` comes from the source system and may name values this corpus does not hold — engagement_weeks and hourly_budget_type both do. Filter on `options`, never on the sentence.
• bounds are observed not enforced — `min` and `max` are the range currently present in the corpus, not a constraint. A filter outside them is accepted and matches nothing; check_prefilter warns when a clause cannot match.

Combining filters

Several fields in one object are ANDed. There is no OR across fields; to widen, loosen a clause rather than adding another. Within a text field, any_words is the OR.

{
  "_combined|title|description|skills": {
    "exact_phrase": "React Native"
  },
  "buyer_payment_verified": {
    "value": "Yes"
  },
  "total_spent": {
    "operator": "greater_than",
    "value1": "5000"
  }
}

Run it through check_prefilter before saving. It returns matched, and a filter that is valid and matches nothing looks exactly like a quiet market — a saved search built on one fires forever without telling you it was the filter. It also returns warnings when a clause cannot match at all, such as a numeric comparison outside the range the corpus holds.

Every field

Grouped by how often they are actually useful, which the catalogue itself ranks. min and max are the values currently present in the corpus, not limits — a filter outside them is valid and matches nothing.

↑ top