SEEK recommends a five stage process for developing software against the SEEK API. This reflects the process we use internally for developing new features:
- Request access to the Developer Dashboard from SEEK.You will be able to provision Playground credentials from the Developer Dashboard’s credentials page once you’re registered. These will grant you limited permissions to the SEEK API’s read-only mock data; use them to test accessing the SEEK API and mapping its data structures. While you can test the input validation of mutations with these credentials, the SEEK API will ultimately forbid requests to mutate our read-only mock data.
- Request access to manage your live partner credentials from SEEK.You will be able to provision live credentials from the Developer Dashboard’s credentials page once you’re approved. These will grant you access to live production data. For partners with existing legacy integrations this will give you access to your existing SEEK hirer relationships.At the same time SEEK will add a relationship between your partner account and an unsearchable SEEK test hirer. Test hirers can export candidate applications and post job ads free of charge, but their job ads don’t appear in SEEK’s search results. This should be sufficient to test your software end-to-end against the SEEK API.
- Make a plan with SEEK to roll out your change to production hirers. There may be additional considerations for switching over from a legacy integration already in production.
- SEEK will remove the relationship between your partner account and the test hirer when it’s no longer needed. The test hirer will be returned to a pool to be reallocated to another partner.
These steps can be repeated at any time as required.
It’s recommended that you continue to use your Playground credentials for exploratory testing as your partner credentials are highly sensitive.
When an issue is found with an integration it’s sometimes difficult to determine which services were involved and how they interacted. SEEK has conventions for additional HTTP request headers to help trace issues across both our systems. These conventions should be used for all server-to-server HTTP requests including GraphQL queries, token requests and attachment file downloads. Some of these conventions should also be applied to requests made from the browser using browser tokens.
User-Agentis 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-Idheader 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-Idheader 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.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.It’s recommended that you generate a UUID for each session and record that UUID along with any relevant log entries.Requests made from the browser should add this header.
POST /graphql HTTP/1.1