SEEK’s location hierarchy has been extended with increased granularity in core Asia-Pacific locations.
If you have already built a supported implementation option in your software,
these changes have been automatically rolled out to your hirers and you can skip to the next section.
Legacy integrations that use static location mappings must move to a supported option as part of this revision.
SEEK can no longer justify the effort of producing mapping files tailored to each partner and the administrative overhead of managing manual updates,
particularly as our ontologies have expanded in scope and are now evolving at a quicker pace.
For reference, our location hierarchy has been revised six times over the past six months.
- If your software can interactively prompt the hirer to select a location from a SEEK-specific autosuggest field, build location suggest then provide the selected location ID to our posting mutations.
- If your software has its own location hierarchy which contains latitudes and longitudes, build nearest locations then provide the first location ID to our posting mutations.SEEK will reliably infer a location based on the closest proximity to the supplied coordinates.
- If your software has its own location hierarchy which lacks latitudes and longitudes, you can provide structured address details to the new
inferLocationquery . This query will attempt to match the details to a location in our hierarchy on a best-effort basis. The ID of the location returned can then be passed to thepositionLocationfield in our posting mutations.
Location inference is less reliable than the other location options and should be used only as a last resort. You should test a significant sample of common locations across multiple countries used by hirers to ensure the returned locations are accurate for your use case.
QueryVariablesResult
CopyGraphQL Explorer
query ($address: SeekPositionAddressInput!, $schemeId: String!) {
inferLocation(address: $address, schemeId: $schemeId) {
id {
value
}
# Enable your software to pre-select a salary currency
currencies {
code
}
}
}If your location hierarchy lacks such structure,
you can provide the address as a single formatted line,
though unstructured input may produce less consistent results:
QueryVariablesResult
CopyGraphQL Explorer
query ($address: SeekPositionAddressInput!, $schemeId: String!) {
inferLocation(address: $address, schemeId: $schemeId) {
id {
value
}
# Enable your software to pre-select a salary currency
currencies {
code
}
}
}SEEK will infer a location based on the closest match to the supplied text.
You should test and fine tune the data format provided by your software,
starting with the following recommended baselines:
Country | Fields | Example |
|---|---|---|
AU | suburb, postcode, country | Cremorne, 3121, AU |
AU | suburb, state, postcode, country | Cremorne, VIC 3121, AU |
NZ | suburb, region , country | Milford Sound, Southland, NZ |
Other | major city, province/state, country | George Town, Penang, MY |
Other | province/state, country | Perak, MY |
The
inferLocation query will only return locations suitable for posting a job ad,
similar to the PositionPosting usage type for location suggest,
and will return null if a valid location cannot be inferred from the provided data.If this occurs, the hirer will be unable to proceed to post their job ad to SEEK,
and you should review the quality of the address details that your software sends to the SEEK API.