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 get started with this integration or if you have questions, contact indeed-ciam-integrations-support@indeed.com.

Complete these steps to use the token exchange grant type (OAuth) to generate an Indeed access token:

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. On the Manage app credentials page, sign in to your Indeed account. Then, select Register new application.

2. On the Provide basic information page, enter your app name and description. For the Credential type, select OAuth 2.0. Then, select Save and contin ue.

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

4. On the Provide additional information page, optionally provide additional information. Then, select Save and continue.

5. On the Preview app page, review your app information. Then, select Complete registration.

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

7. Share your client ID with Indeed so that they can add the registered OAuth client to an allowlist for token exchange.

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	✔	Token that represents the identity of the party on behalf of whom the request is being made. The issuer of the token must provide some ways for Indeed to validate the token. 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 fields in the response 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

In the specified ID token, these claims are inspected in the token.

In addition to all of the fields required by OpenID Connect Core 1.0 incorporating errata set 2 – Standard Claims, Indeed’s Identity system inspects these fields, if available.

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

note

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, contains the client ID of the external application the token was issued for. When the external application presents this token for exchange, this value identifies the token's 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		Time when the user last authenticated. Example: 1741209846
exp Type: JSON number		Indeed rejects any token if the expiration time has passed. 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		Unique ID for the entity that issued the JWT. Value is 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		End user's full name, formatted for display according to their locale and preferences. Example: Job Seeker
email Type: string	✔ for all integrations	User's preferred email address. Must conform to 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	Last name of the user. In some cultures, people have multiple last names. Use the space character to separate multiple last names. Example: Seeker
given_name Type: string		First name of the user. In some cultures, people have multiple first names. Use the space character to separate multiple first names. Example: Job
locale Type: string		User's locale, represented as a BCP47 (RFC 5646) language tag. Typically an ISO 639 Alpha-2 ISO639 language code in lowercase and an ISO 3166-1 Alpha-2 ISO3166‑1 country code in uppercase, separated by a dash. Example: en_US
phone_number Type: string		Phone number. Must be formatted per E164. Example: +1 (425) 555-1212
phone_number_verified Type: boolean		Whether the phone number is verified. If you include the phone number but not 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		Defined in the OpenID Connect specification. The time the end user's information was last updated. 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?