Phase 2: Apply with SEEK

This guide is for partners upgrading from the previous version of Apply with SEEK. New implementations should instead refer to the use case documentation.The new Apply with SEEK offers a similar user experience to its predecessor , though candidates will benefit from the following enhancements:
  • Richer SEEK Profile information available for pre-fill
  • A familiar, localised experience across our SEEK, Jobstreet, and Jobsdb brands
  • Forward compatibility with a streamlined pre-authorization flow
From an integration partner perspective, the new Apply with SEEK brings:To upgrade to the new version of Apply with SEEK, first review its use case documentation:Then, cover the following migration considerations.

Feature comparison

The table below outlines the key differences between the previous and new versions of Apply with SEEK:
Step
Previous version
New version
Legacy client credentials
No support
seek-token parameter included in link-out redirect
Link generated by partner
GraphQL applyWithSeekButton query returns localised button image, label, and link
OAuth 2.0 with authorization code exchanged for access token
Revised authorization flow returns seek-prefill-id to retrieve SEEK Profile and seek-token to track application state
POST endpoint
GraphQL candidateProfile query returns richer information
GET based on returned url
GET based on returned url
Partner pre-fills fields based on returned data
Partner pre-fills fields based on returned data
POST endpoint

Migration considerations

Linking out to a job details page

When a candidate links out from a SEEK job ad, the new Apply with SEEK appends parameters to the query string of your applicationUri:
  • seek-prefill-id is optionally provided by the pre-authorization flow and should be used to pre-fill the apply form immediately
  • seek-token should be persisted for application tracking and subsequent signals
These parameters are intended to be consumed by your apply form, and require additional consideration if your applicationUri links to an intermediary job details page.
We recommend applicationUri to link directly to your apply form. This provides candidates with a more seamless experience, and keeps your job details page isolated from Apply with SEEK business logic.
applicationUri
Copy
- https://example.com/position/123
+ https://example.com/position/123/apply

Option 2: Adapt your job details page for the new version

If your software cannot link directly to the apply form, all intermediary pages will need to propagate the seek-prefill-id and seek-token parameters through to the apply form.This option increases overall complexity as parameter handling will need to be maintained across multiple pages in your software.

Redirecting to an auth landing page

With the previous version of Apply with SEEK, each redirect_uri had to be individually allowlisted via support request. Some integrations adopted a centralised auth landing page to avoid repeating this manual process:
For example, your software may have implemented a landing page https://example.com/seek-auth for use as the Apply with SEEK redirect_uri. Additional state like the apply form path /position/123/apply could be packed into the state parameter in the query string. The landing page could then read the state and use it to internally redirect to the final URL of the apply form.
SEEK authorization pageAuth landing pageApply form
Copy
https://www.seek.com.au/api/iam/oauth2/authorize?redirect_uri=https%3A%2F%2Fexample.com%2Fseek-auth&state=%2Fposition%2F123%2Fapply&advertiser_id={advertiser_id}&client_id={client_id}&response_type=code&scope=r_profile_apply
The new Apply with SEEK encourages your software to point redirectUri directly to the apply form. It does away with the maintenance burden of strict URL allowlists, though your software must follow best practices around URL redirection to protect candidates from phishing attempts.If your software has an existing auth landing page, you have two migration options when you upgrade to the new version.
When a candidate authorizes access to their SEEK Profile, your apply form will receive seek-prefill-id and seek-token parameters on the query string:
apply form
Copy
https://example.com/position/123/apply?seek-prefill-id=def456&seek-token=ghi789
This option allows your software to follow the simplified apply form model from our standard use case documentation.

Option 2: Adapt your landing page for the new version

While the new Apply with SEEK does not explicitly manage the state parameter, your software can include a query string in the redirectUri:
QueryVariablesResult
{
  "input": {
    // The HTTPS URL to redirect the candidate to after authorization.
    // Your software may embed dynamic state in the query string for CSRF protection.
    "redirectUri": "https://example.com/seek-auth?state=%2Fposition%2F123%2Fapply",

    // The identifier for the SEEK hirer that is filling the position.
    // "<Partner Name> on behalf of <Hirer Name>" will be displayed on the authorization page.
    "hirerId": "seekAnzPublicTest:organization:seek:93WyyF1h",

    // The HTTPS URL of your apply form for the specific position.
    "applicationUri": "https://example.com/position/123/apply",

    // An optional hirer-provided free-text job reference.
    "seekHirerJobReference": "REQ-65558",

    // The seek-token received as part of the query string when the candidate arrived from SEEK.
    "token": "eyJqb2JJZCI6MCwiY2FuZGlkYXRlSWQiOjAsInNlc3Npb25JZCI6IiJ9"
  }
}
Your auth landing page will receive seek-prefill-id and seek-token parameters on the query string, and must propagate them to your apply form for pre-fill and application tracking:
Auth landing pageApply form
Copy
https://example.com/seek-auth?state=%2Fposition%2F123%2Fapply&seek-prefill-id=def456&seek-token=ghi789
This option increases overall complexity as parameter handling will need to be maintained across multiple pages in your software.