Token exchange grant type (OAuth)

Exchange a security token for an Indeed access token.

 

legal notice

By using this API and its documentation and building an integration, you agree to the Additional API Terms and Guidelines.

Use Indeed's token exchange grant type (OAuth) to generate an Indeed access token.

Token exchange grant type (OAuth) steps

To start this integration or ask questions, contact indeed-ciam-integrations-support@indeed.com.

Complete these steps:

Token exchange grant type

#	Step
1.	Register your app.
2.	Generate the Authorization Basic header value.
3.	Get an access token.

Register your app

Japan only

1. Sign in to your Indeed account on the Manage app credentials page, and select Register new application.

2. Enter your app name and description on the Provide basic information page. For Credential type, select OAuth 2.0, and select Save and continue.

3. Select Client credentials on the Select OAuth grant types page, and select Save and continue.

4. Add more details on the Provide additional information page if needed, and select Save and continue.

5. Review your app information on the Preview app page, and select Complete registration.

   Note your client ID and secret on the Credentials page. Do not share your secret.

6. Share your client ID with Indeed so Indeed can add the registered OAuth client to the token exchange allowlist.

Outside of Japan

To build an Indeed Apply XML integration, contact the Indeed Client Success team. After you sign the Developer Agreement, Indeed sets up an app that integrates Indeed APIs and services into your product.

Sign in to Partner Console to view your app and its Indeed Apply API token credentials:

• The API token credentials are a client ID and a client secret.
• Include the API token with each job you post to Indeed.

Generate the Authorization Basic header value

See also Basic Authentication Scheme in RFC 2617: HTTP Authentication: Basic and Digest Access Authentication.

To generate the Authorization Basic header value:

1. Concatenate the client_id and client_secret with a colon (:) as a separator.

   base64.encode("<client_id>:<client_secret>");

2. Apply the Base64-encoding algorithm to the string:

   base64.encode("5e175cbb7f88e2048bd95323bbc9ca2fcec32ad60f95f7ee66ab53e099abe6f3:pJ4qRe2sdXRP0Whr3bwz9D37exFuuOtqJDRHMmmlLWV7J25rH7oItrPNCKzhaQf2");

3. Pass the Base64-encoded string as a basic HTTP Authorization header:

   Authorization: Basic NWUxNzVjYmI3Zjg4ZTIwNDhiZDk1MzIzYmJjOWNhMmZjZWMzMmFkNjBmOTVmN2VlNjZhYjUzZTA5OWFiZTZmMzpwSjRxUmUyc2RYUlAwV2hyM2J3ejlEMzdleEZ1dU90cUpEUkhNbW1sTFdWN0oyNXJIN29JdHJQTkNLemhhUWYy

Get access token

To use the token exchange grant type to get an access token, make a POST request to the https://apis.indeed.com/oauth/v2/tokens endpoint with these HTTP request headers:

POST https://apis.indeed.com/oauth/v2/tokens
Content-Type: application/json
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

grant_type=urn:ietf:params:oauth:grant-type:token-exchange&subject_token=xxxxx.yyyyy.zzzzz&subject_token_type=urn:ietf:params:oauth:token-type:id_token

To get an access token, make a POST request to the https://apis.indeed.com/oauth/v2/tokens endpoint with Authorization: Bearer <access_token> and Content-Type request headers, and request body parameters.

This curl example gets an access token:

curl -L 'https://apis.indeed.com/oauth/v2/tokens' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Authorization: Bearer <access_token>' \
  -d 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange' \
  -d 'client_id=<client_id>' \
  -d 'client_secret=<client_secret>' \
  -d 'subject_token_type=urn:ietf:params:oauth:token-type:id_token' \
  -d 'scope=email offline_access' \
  -d 'subject_token=xxxxx.yyyyy.zzzzz'

The request headers are:

Get an access token

Header	Value
Authorization	Bearer <token> where <token> is your access token.
Content-Type	application/json

The request body parameters for oauth/v2/tokens are:

oauth/v2/tokens request body parameters

Request body parameter	Required	Value
grant_type	✔	urn:ietf:params:oauth:grant-type:token-exchange Type: string
scope	Optional	Scopes to be granted in the issued Indeed token. See Scopes. Example: openid
subject_token	✔	The token representing the identity of the party the request is made on behalf of. The token issuer must give Indeed a way to validate it. Indeed supports only ID tokens. Example: xxxxx.yyyyy.zzzzz
subject_token_type	✔	Type of token passed in the subject_token field. Example: urn:ietf:params:oauth:token-type:id_token.

A successful JSON response is:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": "<access_token>",
  "scope": ""
  "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
  "token_type": "Bearer",
  "expires_in": 1419356238
}

A failed JSON response is:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "invalid_request"
}

The response fields are:

Response fields

Response field	Type	Description
access_token	String	Your access token. Example: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Ikpv[...]
error	String	The error type. Example: "error": "invalid_request"
error_description	String	A description of the error. Example: "error_description": "Invalid Request."
expires_in	Integer	Token is valid for one hour (3600 seconds). Example: 3600
issued_token_type	String	The token type of the issued token. Example: urn:ietf:params:oauth:token-type:access_token
scope	String	The actual permissions granted to your app. For example, email and offline_access scopes. Scopes are space-delimited. Example: email offline_access See Scopes.
token_type	String	Value is always Bearer. Example: Bearer

ID tokens

Indeed inspects these claims in the specified ID token.

Beyond the fields required by OpenID Connect Core 1.0 incorporating errata set 2 – Standard Claims, Indeed's Identity system inspects these fields when available.

The ID token is a JSON Web Token (JWT). The following table defines the supported and required fields in the JWT body:

OpenID Connect Core 1.0 incorporating errata set 2 – Standard Claims defines all fields except auth_ip.

See also OpenID Connect Core 1.0 incorporating errata set 2 – Standard Claims.

ID tokens

Field	Required	Description
aud Type: string		The intended recipient of the ID token. In the token exchange flow, this field holds the client ID of the external application that received the token. When the external application presents this token for exchange, this value identifies the original audience. Example: 6ae943d9e10b6576f51185ca5ce3353f
auth_ip Type: string		Correctly formatted IPv4 address of the user when they signed in. See RFC 1918. Example: 160.67.221.147
auth_time Type: JSON number		When the user last authenticated. Example: 1741209846
exp Type: JSON number		Indeed rejects any token after the expiration time. The issued access token matches the exp value. Example: 1741209848
iat Type: JSON number	✔ for all integrations	Time when the JWT was issued. Example: 1741209847
iss Type: string		The unique ID of the entity that issued the JWT. The URI of the issuing system. Example: https://partner.com/
sub Type: string	✔ for all integrations	User ID in the identity provider. Must map to externalId in SCIM. Example: CU1234
name Type: string		The end user's full name, formatted for display per their locale and preferences. Example: Job Seeker
email Type: string	✔ for all integrations	The user's preferred email address. Must follow the Addr-Spec Specification in RFC 5322. Example: jobseeker123@indeed.com
email_verified Type: boolean		If you omit this value, Indeed assumes the partner has not verified the user's email address. Example: true or false
family_name Type: string	✔ for some integrations	The user's last name. In some cultures, people have multiple last names. Separate multiple last names with a space. Example: Seeker
given_name Type: string		The user's first name. In some cultures, people have multiple first names. Separate multiple first names with a space. Example: Job
locale Type: string		The user's locale as a BCP47 (RFC 5646) language tag. Typically a lowercase ISO 639 Alpha-2 ISO639 language code and an uppercase ISO 3166-1 Alpha-2 ISO3166‑1 country code, separated by a dash. Example: en_US
phone_number Type: string		The user's phone number. Must follow E164 formatting. Example: +1 (425) 555-1212
phone_number_verified Type: boolean		Whether the phone number is verified. If you include the phone number but omit phone_number_verified, Indeed assumes the identity provider has not verified the user's phone number. Example: true or false
updated_at Type: JSON number		When the end user's information was last updated. Defined in the OpenID Connect specification. Example: 1741201234

RFCs

• RFC 1918: Address Allocation for Private Internets
• RFC 5322: Internet Message Format
• RFC 5646: Tags for Identifying Languages
• RFC 8693: OAuth 2.0 Token Exchange

See also

• HTTP request headers
• oauth/v2/tokens endpoint
• Error response
• Troubleshoot OAuth errors

 

Was this page helpful?