application/json content type for HTTP POST requests to its GraphQL endpoint.
It may support additional content types like application/graphql+json once they have been stabilised in a GraphQL specification.Response and request bodies in the SEEK API are encoded in UTF-8.The SEEK API supports two types of GraphQL operations: queries and mutations.variables.
This is analogous to SQL prepared statements and prevents code injection .POST https://graphql.seek.com/graphql HTTP/1.1
Accept-Language: en-AU
Authorization: Bearer PARTNER_TOKEN_HERE
Content-Type: application/json
User-Agent: example-application/1.2.3
X-Request-Id: 6837f359-0335-418c-80dc-9d98a57a330c
X-Session-Id: b5a8774c-c450-4906-a25c-861bce129106
{"query": "query($id: String!) { hiringOrganization (id: $id) { name } }",
"variables": {
"id": "seekAnzPublicTest:organization:seek:93WyyF1h"
}
}# Inline arguments are only used to simplify these examples.# Parameterise your production queries as per advice above.
# Correct: omit unused argumentquery Omit {
events(schemeId: "seekAnzPublicTest") {
pageInfo {
hasNextPage
}
}
}
# Incorrect: set unused argument to nullquery Null {
events(schemeId: "seekAnzPublicTest", after: null) {
pageInfo {
hasNextPage
}
}
}
# Incorrect: set unused argument to an empty stringquery EmptyString {
events(schemeId: "seekAnzPublicTest", after: "") {
pageInfo {
hasNextPage
}
}
}
# Incorrect: create variable for unused argumentquery Variable($after: String!) {
events(schemeId: "seekAnzPublicTest", after: $after) {
pageInfo {
hasNextPage
}
}
}last argument in the query above and it is deprecated from the SEEK API.
If you already omit the argument, the deprecation will not impact your software.
On the other hand, if you specify the argument and set it to null or a variable,
you will have to manually update your software to remove it from your requests,
which is pure busywork.query ($filter: EventsFilterInput!, $schemeId: String!) {
events(filter: $filter, schemeId: $schemeId) {
pageInfo {
hasNextPage
}
}
}location query with the following selection set:query ($id: String!) {
location(id: $id) {
contextualName
}
}query ($id: String!) {
location(id: $id) {
currencies {
code
}
}
}hasPreviousPage field in the query above and it is deprecated from the SEEK API.
If you already omit the field, the deprecation will not impact your software.
On the other hand, if you select the field,
you will have to manually update your software to remove it from your requests,
which is pure busywork.User-Agent is a standard HTTP header identifying the service making an HTTP request.While your HTTP client library likely already sends a generic User-Agent, it’s recommended that you override this to include the name and version of the service making the request.
This makes it easier to trace a request back to a specific deployment of your software when debugging an issue.Requests made from the browser do not need to alter this header.X-Request-Id header is a SEEK extension for tracing a request as it passes through our systems.It’s recommended that you generate a UUID for each HTTP request and record that UUID along with any relevant log entries.Requests made from the browser should add this header.X-Session-Id header is a SEEK extension for grouping requests in the same interaction together.
This helps isolate the sequence of events that led to an issue or error, especially for high traffic integrations.It’s recommended that you generate a UUID for each session and record that UUID along with any relevant log entries.
You can choose which definition of session makes the most sense for you.
For example, an interactive user flow for creating & posting a job ad might be assigned a single session.
Or, every time your webhook endpoint is called you might generate a new session for all HTTP requests related to processing its events.Requests made from the browser should add this header.POST /graphql HTTP/1.1
User-Agent: example-application-import-webhook/1.2.3
X-Request-Id: 749fbdc9-fbe5-40e9-b5ae-fee3375f1e28
X-Session-Id: 6eb0559a-cb91-4178-bb3d-9f5513e9ecc2
Language | Locale |
|---|---|
Australian English | en-AU |
Bahasa Indonesia | id-ID |
Thai | th-TH |
Accept-Language HTTP request header to indicate the language preferences of the end user.
A web browser will automatically set this header on client-side requests to the SEEK API that use a browser token,
but you will need to manually propagate the preference for requests that originate from your software’s backend.The Accept-Language header drives translations for user-facing response fields,
such as copy for an interactive Job Posting feature like ad selection.
The language(s) of the response may be described in the standard Content-Language HTTP response header,
falling back to Australian English (en-AU) where translations for the preferred languages are not available.Unsupported region subtags of a language will resolve to a supported subtag.
For example, consider the following Accept-Language header:Accept-Language: en-US,th;q=0.9,
en-US),
it will fall back to the associated primary language (en) and return content in Australian English (en-AU).
This fallback is evaluated ahead of the second preference of Thai (th).While the SEEK API works fine with plain old HTTP clients,
you can make the most of it with the GraphQL ecosystem .query ($hirerId: String!, $jobCategoryId: String!) {
# first query field
hiringOrganization(id: $hirerId) {
name
}
# second query field
jobCategory(id: $jobCategoryId) {
name
}
}[{
"query": "query($id: String!) { hiringOrganization (id: $id) { name } }",
"variables": {
"id": "seekAnzPublicTest:organization:seek:93WyyF1h"
}
},
{
"query": "query($id: String!) { jobCategory (id: $id) { name } }",
"variables": {
"id": "seekAnzPublicTest:jobCategory:seek:27HXTkNXh"
}
}
]id or _id string field.Such heuristics may not work well with the SEEK API,
which uses a non-primitive object identifier and various field names from HR-JSON:{"profileId": {
"value": "seekAnzPublicTest:candidateProfile:apply:7DtW6Q68gk2R4okNGhvg1Y"
}
}new ApolloClient({
defaultOptions: {
query: {
fetchPolicy: 'no-cache'
},
watchQuery: {
fetchPolicy: 'no-cache'
}
}
});