Frequently asked questions

Answers to common questions about integrating with Indeed APIs.

Filter by topic

Filter by OAuth flow

157 questions

Your OAuth credentials are a client ID and secret. You access these credentials in Partner Console. You exchange your client ID and secret for an access token, which is a long, garbled string. Include this token in every API call to authenticate your app's identity and its permissions. Access tokens are valid for one hour.

If you are an ATS that is building an integration that requires the authorization code flow (3-legged OAuth), and you do not have an OAuth application registered with Indeed, you must create an OAuth client ID.

When you become an Indeed partner, Indeed sets up an app that integrates Indeed APIs and services into your product. Indeed grants your Indeed user account access to Partner Console, which you use to access your app's OAuth credentials: a client ID and secret.

Related:Which client credentials do I use?·Why do I need a client ID and secret?

You need these OAuth credentials to exchange them for an access token. Then, you include your access token on Indeed API calls to authenticate your app's identity and its permissions.

Access tokens expire in one hour, so you exchange your OAuth credentials for an access token every hour.

For the authorization code flow (3-legged OAuth), your app must request an authorization code, which grants your app permission to act on behalf of a user and their associated employer account. For example, use this flow to create an Indeed interview or create a sponsored campaign.

The user of the account to which you want access grants you this code, which expires in 10 minutes. After you get an authorization code, log in to Partner Console with your Indeed user account.

On the Dashboard, select your app in the Apps list. The Credentials tab on the app details page lists your OAuth credentials: a client ID, secret, and authorization code. You exchange these credentials for an access token.

Related:When do I request an access token?·For an access token request, what details do I receive?

When you request an access token, you receive a response like this:

{
  "access_token": "<access_token>",
  "refresh_token": "<refresh_token>",
  "id_token": "<id_token>",
  "scope": "offline_access employer_access email",
  "consented_scope": "offline_access employer_access email",
  "convid": "1er835qvtu54n800",
  "token_type": "Bearer",
  "expires_in": 3600
}

Access the JWT debugger.

To get an authorization code, make a POST request to the https://secure.indeed.com/oauth/v2/authorize endpoint.

You must specify the client_id, redirect_uri, prompt=select_employer, and response_type. See Query parameters for oauth/v2/authorize.

Request the interviews.schedule and employer_access scopes. See the scope parameter.

Indeed redirects the user to the page at the redirect_uri endpoint with the code and state parameters appended. For example:

http://www.companyname.com/oauth/indeed?code=rXZSABCyYQHQ&state=employer12

Make a POST request to the https://apis.indeed.com/oauth/v2/tokens endpoint.

You must provide the code, client_id, client_secret, redirect_uri, and grant_type parameters. Optionally, specify the employer parameter.

See Get access token that represents an employer.

This authorization link triggers the display of these screens:

Screen	Description
Authentication	Appears when the user is logged out of Indeed.
OAuth consent	Enables a user to grant consent for any scopes that the OAuth app requests, such as the employer_access scope.
Indeed employer selection	Enables a user to select an employer from a list of employers associated with the user account.

If an employer is associated with the user account, you must specify prompt=select_employer when you request the authorization code. This parameter prompts the authorizing user with an Indeed employer selection screen, from which the user chooses the employer account.

An access token can represent only one employer. To switch employers, get an access token.

The employer value is the advertiser ID in the ID token.

All Indeed Apply Sync integrations are required to have Screener Questions, Equal Employment Opportunity (EEO) questions through updated schema that includes Demographic Data capture (if supporting US employers), and Disposition Sync capabilities.

This short video summarizes the new functionalities and the actions your organization must take. You can access a copy of the Indeed Apply Enhancements presentation.

Indeed requires Disposition Sync to complete the data loop and accurately track an applicant's progress through the hiring process. This capability is essential for improving matching algorithms and optimizing performance for clients. Disposition Sync is a mandatory component of all Indeed Apply Sync integrations, along with Screener Questions and EEO compliance (where applicable).

Indeed continuously evaluates and adjusts its obligations in response to evolving laws and regulations. As legal requirements change, Indeed remains committed to compliance and updates policies and practices to ensure alignment with applicable data protection and privacy laws.

Indeed fully complies with GDPR and other relevant privacy legislation. The return of Disposition Sync data aligns with legal and compliance obligations, as it is used solely to improve job matching and hiring outcomes. All data processing is conducted in accordance with privacy policies and applicable regulations. For more information on Indeed's GDPR compliance, see Indeed GDPR Compliance.

While employer-specific data does not improve client-specific matching today, disposition data helps Indeed understand which candidates employers consider strong fits. This feedback is directly fed into Indeed's matching models, allowing for fine-tuned candidate recommendations.

Using candidate disposition data from ATSs, indexed jobs receive 14% more positive outcomes overall.

A common reason employers opt-out of Indeed Apply integrations is because they do not support voluntary EEO and required knockout questions.

Indeed has a company-wide requirement that all integrations must support screener questions and flag EEO questions for US jobs. The employer remains responsible for how they ask the demographic questions. By requiring that all integrations support the flagging of EEO questions for US jobs, Indeed drives higher-quality integrations that provide job seekers with a consistent experience.

Your client credentials are an Indeed Apply API token and secret. You access these credentials in Partner Console.

Use the shared API secret, which has the Indeed Apply credential type.

Indeed uses the HMAC-SHA1 algorithm to compute a message signature. This signature is sent as an HTTP X-Indeed-Signature header.

Indeed Apply sends a POST request to your postUrl that contains an HTTP header that you can use to verify the authenticity of the POST request.

Today, the EEO/Demographic questions are limited to U.S.-based jobs for EEO compliance.

Indeed has qualification-type questions. These are non-blocking questions that enable the applicant to move to the next section in the apply flow even if the answer does not meet the specification defined in the qualification. The application is delivered in this case.

You can use the Indeed Apply Questions tool to verify the syntax of your Screener Questions JSON file. This tool shows how screener questions appear in the Indeed Apply application flow.

To test your integration before pushing a job or integration live, Indeed provides the Indeed Apply XML configuration testing tool. On the Configurable Parameters tab, provide relevant information to start testing the end-to-end apply flow.

See Test your Indeed Apply configuration.

For POST requests, an application is a duplicate if it has the same job ID and is from the same job seeker email as an Indeed application within the last 120 days.

To determine whether an application is a duplicate when responding to the POST request, do not use applications originally submitted from a source other than Indeed. Additionally, do not consider applications that are from the same job seeker email to a different job ID at the same company a duplicate.

For XML that is crawled on a URL or hosted on an FTP server you provide, Indeed refreshes the job data four times a day at six-hour intervals, starting from the time of the last request. For Indeed-hosted FTPs, Indeed refreshes the XML feed when it receives a new file, as often as every two hours. More frequent file uploads can delay updates to the job data. To correct a delay in feed indexing, scale back the frequency of uploads.

As long as you include the standard fields, you can include any fields, such as <branch_id>. If specific information must appear on Indeed, use the <description> field.

Visibility in search results is based on Indeed's visibility rules. The Search Quality team prioritizes jobs that are legitimate, unique, have detailed descriptions and locations, and are easy to apply for.

If the data on the client site corresponds to a data target in Indeed and if the tags match one of the previously mentioned tags, then it appears in the search results page.

However, if the data tag does not match an Indeed tag, its visibility depends on a variety of factors, such as the market in which the job is in, whether search results page is being viewed on desktop and mobile, and other factors.

If the tag contains information that must appear, have the client add the information inside the <description> tag.

Jobs that do not meet these criteria might be hidden from search results. Make sure your clients follow the search quality team's best practices for posting.

If clients have issues finding their jobs on Indeed, reach out to Indeed for assistance.

Indeed requires a URL to the job description, and not to the apply page, for these reasons:

• If Indeed Apply fails, Indeed directs the job seeker to the job URL.
• If a client opts out of Indeed Apply, Indeed needs a method for job seekers to apply.
• The Indeed aggregation engine needs an active URL to confirm job content and job activity.

For companies that are new to Indeed, or for new job sources from companies already on Indeed, Indeed requires a contact email address to verify the account and enable organic syndication.

Although Indeed does not use the email address in some cases, Indeed requires it for all jobs.

Provide the job in every language where an open position exists as a unique job in the XML feed. If you duplicate the reference number in the XML feed, only the first appearance of the job appears on Indeed.

Provide the job in every location where an open position exists. Region-wide postings that are not region-wide jobs are rejected for organic visibility on Indeed. Each job must have its own unique location, unique reference number, and represent a unique job. Otherwise, it loses visibility on Indeed.

To post a state-wide job, send the state and country information by using those elements, and leave the <city> and <postalcode> elements blank.

Example: a statewide job in Texas:

<city>
  <![CDATA[]]>
</city>
<state>
  <![CDATA[TX]]>
</state>
<country>
  <![CDATA[US]]>
</country>
<postalcode>
  <![CDATA[]]>
</postalcode>

Example: a statewide job in Tokyo:

<city>
  <![CDATA[]]>
</city>
<state>
  <![CDATA[東京都]]>
</state>
<country>
  <![CDATA[JP]]>
</country>
<postalcode>
  <![CDATA[]]>
</postalcode>

To post a country-wide job, send the country using the <country> element, and send a blank value for <city>, <state>, and <postalcode>.

Example: a US nationwide job:

<city>
  <![CDATA[]]>
</city>
<state>
  <![CDATA[]]>
</state>
<country>
  <![CDATA[US]]>
</country>
<postalcode>
  <![CDATA[]]>
</postalcode>

Example: a Japan nationwide job:

<city>
  <![CDATA[]]>
</city>
<state>
  <![CDATA[]]>
</state>
<country>
  <![CDATA[JP]]>
</country>
<postalcode>
  <![CDATA[]]>
</postalcode>

Post jobs to the most specific and accurate location possible. All jobs must include all elements used in the feed, even if those elements are blank, as the examples show.

You can use the <city> or <state> elements to indicate that a job is fully remote by sending the value "remote". If you use this value, enter "remote" in both elements. Alternatively, enter "remote" in one element and leave the other blank. Do not enter "remote" in one element and a real location in the other element.

If you have a job that is fully remote but requires residency in a specific state, you can use the <remotetype> element in conjunction with the statewide posting schema.

Japan only. When posting remote jobs in Japan, leave <city> and <state> blank and use <remotetype>. If you have a fully remote job that requires residence in a specific prefecture, you can use the <remotetype> element in combination with the prefecture-wide posting schema.

Example: A fully-remote job in Texas:

<city>
  <![CDATA[]]>
</city>
<state>
  <![CDATA[TX]]>
</state>
<country>
  <![CDATA[US]]>
</country>
<postalcode>
  <![CDATA[]]>
</postalcode>
<remotetype>
  <![CDATA[Fully remote]]>
</remotetype>

Example: A fully-remote job in Tokyo:

<city>
  <![CDATA[]]>
</city>
<state>
  <![CDATA[東京都]]>
</state>
<country>
  <![CDATA[JP]]>
</country>
<postalcode>
  <![CDATA[]]>
</postalcode>
<remotetype>
  <![CDATA[Fully remote]]>
</remotetype>

Remote type values:

• Fully remote: The employee works remotely or from home.
• Hybrid remote: The employee works both in-office and remotely on a consistent basis.

Example: a fully remote job in the US:

<city>
  <![CDATA[Remote]]>
</city>
<state>
  <![CDATA[]]>
</state>
<country>
  <![CDATA[US]]>
</country>
<postalcode>
  <![CDATA[]]>
</postalcode>
<remotetype>
  <![CDATA[Fully remote]]>
</remotetype>

Example: a fully remote job in Japan:

<city>
  <![CDATA[]]>
</city>
<state>
  <![CDATA[]]>
</state>
<country>
  <![CDATA[JP]]>
</country>
<postalcode>
  <![CDATA[]]>
</postalcode>
<remotetype>
  <![CDATA[Fully remote]]>
</remotetype>

Example: a hybrid remote job in Austin, TX:

<city>
  <![CDATA[Austin]]>
</city>
<state>
  <![CDATA[TX]]>
</state>
<country>
  <![CDATA[US]]>
</country>
<postalcode>
  <![CDATA[78701]]>
</postalcode>
<remotetype>
  <![CDATA[Hybrid remote]]>
</remotetype>

Example: a hybrid remote job in Minato, Tokyo:

<city>
  <![CDATA[港区三田]]>
</city>
<state>
  <![CDATA[東京都]]>
</state>
<country>
  <![CDATA[JP]]>
</country>
<postalcode>
  <![CDATA[100-8602]]>
</postalcode>
<remotetype>
  <![CDATA[Hybrid remote]]>
</remotetype>

No, Indeed Apply is enabled for all client jobs. Clients can opt-out of Indeed Apply at an account level, but not at the job level.

Some steps and considerations are:

• Opt in from ATS: You can opt in or opt out of Indeed Apply directly from your ATS platform. For assistance, contact your ATS.
• Troubleshooting: If Indeed Apply does not work as expected, make sure the client opted in. If issues persist, provide examples of jobs where Easy Apply does not show up and contact Indeed support.

Use the <state> field for Japanese prefectures.

You can ask them to visit your site, but you cannot require them to answer additional questions to complete the application.

Yes. The X-Indeed-Signature header is required to authenticate POST requests from Indeed. Indeed returns the HTTP 401 response code when the signature does not match.

Job Sync API has the same capabilities as the Indeed Apply XML feed. Use Job Sync API instead of an XML integration.

After integrating with the Job Sync API, submit your integration for review.

When you onboard, an app is created with 2-legged OAuth credentials (client ID and secret). Get them in Partner Console, exchange them for an access token, and include it in API calls. Tokens expire after one hour.

Download the schema.

Your OAuth credentials are a client ID and secret, accessible in Partner Console. Exchange them for an access token and include it in every API call to authenticate your app. Access tokens expire after one hour.

Call APIs in real time to keep jobs fresh.

Indeed assigns each client a tier and rate limit based on their needs. See Rate limiting.

No. You can only get the sum.

The Indeed UI changes frequently, so no.

Up to 100 jobs, but create only one per request due to HTTP request size limits.

Jobs are published as soon as you post them.

1. Call createSourcedJobPostings to create the job on Indeed. Set employerIds to associate the posting with the employer.

   Example: type is FOOATS_EMPLOYER_ID and employer ID is abc123 in your ATS. Call createSourcedJobPostings with:

   {
     "employerIds": [
     {
       "type": "FOOATS_EMPLOYER_ID",
       "id": "abc123"
     }]
   }

   Provision the Employer Data API to create this ID. View it in Partner Console.

2. Call patchEmployer with these values:

   {
     "id":
     {
       "type": "FOOATS_EMPLOYER_ID",
       "id": "abc123"
     }
   }

   id must equal employerIds. For details, see Employer Data.

For each employer, choose a unique sourceName value. The sourceName is a human-readable company or organization name for a group of jobs, such as a parent organization, that are managed together and that is hiring for the role.

This value is not a numeric value or ID. However, you can append a numeric value or ID to the name for uniqueness. For example:

Distinguish employers in job postings

Do	Don't
sourceName: "Actual Organization Name"	sourceName: "ID 12345"
sourceName: "Actual Organization Name 12345"	sourceName: "ID 12345"

Multiple job groups under one employer: Use a unique value per job group. For subsidiaries or franchises with many branded locations, use the same sourceName. The value must be unique across job groups and have a single sourceType (organization type).

Company name change: Keep the original sourceName; update companyName to the new name.

Franchises managed separately: Use a value such as store number or store ID:

sourceName: "ConvenienceMart store ID 345"

Duplicate source names: Make the name unique (for example, add location) so users can tell sources apart.

Branches that manage jobs separately: Use unique values. Example: ConvenienceMart has two branches and three stores. For each branch and store to manage jobs separately, use these companyName and sourceName combinations:

companyName and sourceName combinations

Branch	Store	companyName and sourceName definitions
Tokyo	Shibuya station	companyName: "ConvenienceMart Tokyo branch, Shibuya station store" sourceName: "ConvenienceMart Tokyo branch, Shibuya station store"
	Shinjuku station	companyName: "ConvenienceMart Tokyo branch, Shinjuku station store" sourceName: "ConvenienceMart Tokyo branch, Shinjuku station store"
Osaka	Osaka station	companyName: "ConvenienceMart Osaka branch, Osaka station store" sourceName: "ConvenienceMart Osaka branch, Osaka station store"

Set isGlobalDefault to true to use this employer across all Indeed languages and countries.

Indeed uses the client's contact email to verify the posting business entity. contactEmail is not displayed.

A remote job does not require in-person attendance at a specific work site.

Someone can perform a:

• Remote national job from anywhere in the nation.
• Remote regional job from anywhere in a region, such as a prefecture.

To define a remote national or regional job, set the following fields:

Remote job type	remoteType	cityRegionPostal	streetAddress
National	Fully Remote	Leave blank.	Leave blank.
Regional	Fully Remote	Leave empty for jobs in Japan; otherwise set to the region. note If set to a city, the job is not remote.	Leave blank.

createSourcedJobPostings does not contain a field that is equivalent to the XML <keywords> tag.

Post one job posting for each position and location pair.

Changing jobPostingId, sourceName, or client ID causes the API to return a new sourcedPostingId.

Before changing any of these fields, call expireSourcedJobsBySourcedPostingId with the current sourcedPostingId to expire the job.

Always store sourcedPostingId. You need it to expire or reactivate jobs. See Expire job postings.

In the description, specify the expected duration to complete the job.

For example:

If 1.2M JPY for three months project, specify 0.4M JPY/month

To define a salary range or fixed salary, set these fields:

• minimumMinor
• maximumMinor

Define salary range or fixed salary

To define	minimumMinor	maximumMinor
Salary range	Set to minimum salary.	Set to maximum salary.
Salary range with minimum salary only	Set to minimum salary.
Fixed salary	Set to fixed salary.	Set to fixed salary.

Include this data in these fields:

Define jobPostingId and jobRequisitionId

Field	Value
jobPostingId	Unique ID across your ATS (a UUID is allowed). Reposting with this ID can reopen a previously expired job.
jobRequisitionId	Human-readable ID; uniqueness across the ATS is not required. Ideally unique per client within a sourceName. Recruiters use it to distinguish jobs with the same title.

Upserting versus updating job postings on Indeed

• If you submitted the job posting on Indeed, upsert the posting.
• If another partner submitted the job posting on Indeed, update the posting. The update operation is primarily for ad agencies.

Japan Only. All partners except advertising agencies and Indeed PLUS Publisher Network partners can update the posting.

Call createSourcedJobPostings with your job updates. Use the same jobPostingId, sourceName, and OAuth client ID as at creation—Indeed deduplicates on these. Include all required job details even when unchanged.

Japan required it previously; it is no longer used.

Call findEmployerJobsPartner to list your job postings; the response includes sourcedPostingId per job. Use that ID with createSourcedJobPostings or updateSourcedJobPostings to update, or with expireSourcedJobsBySourcedPostingId to expire.

Jobs that do not meet Indeed's standards may be reviewed and require more information from the hiring company. To keep jobs visible to job seekers, follow Job Posting Standards - English or Job Posting Standards - Japanese.

After you create a job posting, it takes one to two hours to appear on Indeed and become searchable.

Indeed PLUS is integrated with multiple job boards. Each job board determines which fields appear.

For jobs in Japan: For information on job postings, see Japan-specific job field visibility. For information on employers, see Japan employer field visibility.

No.

To enable job visibility for your clients, see the Job Sync API guide.

In the ATS, clients see an image for each job that indicates whether the job:

• Is searchable on Indeed.
• Needs sponsorship to become searchable.

• Is not found because either:

  • The job does not exist.
  • The user does not have access to that job.

When a client clicks on an image, they access additional information about the job on Indeed.

Your ATS jobs

When a client clicks on an image, several statuses can appear. See Job status.

When a user views a job in your partner UI, you can update the status once per hour. Indeed does not control this.

Yes.

No, they show Searchable.

Job seekers do not see these jobs in Indeed search results.

No. You can view job visibility for open jobs only.

Visibility booleans for expired jobs can be inaccurate. Do not show them to your users.

Indeed compares the job volume from your ATS feed with the number of jobs visible on the employer's career site. If Indeed captures any discrepancies, Indeed follows up to investigate gaps and ensure compliance with contractual obligations.

If each ATS partner submits all jobs they have access to, the ATS is compliant. When feed and career site jobs differ, partner managers help you find which jobs might be missing and from which client.

To withhold a job from Indeed (for example, future jobs or for privacy or confidentiality), the employer must submit a cease and desist on company letterhead. Share the letter with your partner manager or, if unmanaged, send it to marketplacesupport@indeed.com.

Employers can opt out of confidential or future job listings. Indeed keeps a record of the job; it does not appear in search or in the employer's account.

Call expireSourcedJobsBySourcedPostingId to expire a job posting. The job no longer appears on Indeed.

To reactivate, see Reactivate an expired job.

It usually persists. It can change if the job stays expired for more than 30 days.

Call createSourcedJobPostings to get the sourcedPostingId.

To expire a job posting, call expireSourcedJobsBySourcedPostingId with that job's sourcedPostingId.

To reactivate an expired job, call createSourcedJobPostings with the same jobPostingId and sourceName as the expired job, as when updating an active job.

Update datePublished to set the reactivation date in your ATS.

You can reactivate a job within 30 days after it expires.

After 30 days, Indeed might archive job statistics and configuration. Reactivating after 30 days can return a new sourcedPostingId. Ensure your code handles both the same and a new sourcedPostingId.

Save the sourcedPostingId. Use it to expire or reactivate jobs.

Call the API to expire jobs.

GRAPHQL_PARSE_FAILED indicates a syntax error in the GraphQL operation string, often from unescaped HTML in the description field. See Job description formatting and GRAPHQL_PARSE_FAILED error.

Issues can occur when posting jobs. Review and fix your data for a successful integration.

Job posting issues

Issue	Description
hasProbationaryPeriod defaults to UNKNOWN	In Japan, that value often fails screening. The field does not apply in other locales.
Data is not properly formatted	Improperly formatted data results in invalid API calls, indicating untrustworthy integration data. See Create job posting.
Job links do not lead to jobs	Provide links to job detail pages on your site. Indeed uses these to verify job content consistency and validity. Ensure links lead to job detail pages, not application forms or other pages. Valid links help Indeed keep data aligned and enable job seekers to verify jobs on your corporate website.
Job descriptions are incomplete	Include all required information in job descriptions. Data in specific fields is not always displayed to job seekers. Job descriptions are the ultimate source of truth. See Job description formatting.
Partner site and Indeed job description layout differ	Indeed checks your website to confirm content matches. If the job description layout differs significantly, Indeed can mark the job inactive due to content mismatch and expire it. Keep job description order consistent between your site and Indeed data.
Data is incompatible with Indeed systems	If Indeed determines a considerable portion of your data causes incorrect displays, you must fix it. Considerable portion is judged by issue prevalence and impact on job seekers. Example: providing "Paris" when you meant "Paris, Texas, USA".
Job content misuses API fields	Providing clickbait in title, non-location data in location, or other irrelevant information can cause Indeed to block your integration. Considerable portion is judged by issue prevalence and impact on job seekers.
Jobs are not up to date	Jobs on Indeed must be expired or updated to match your site. Outdated jobs cause issues for job seekers. Keep jobs current, or Indeed can block your integration or expire out-of-sync content. See Upsert job posting.

Usually the client lacks access to the job.

Have the client contact Indeed Support so Indeed can link their employer account to their jobs.

Most Job Sync API errors include information to help you triage.

See Troubleshoot GraphQL errors.

If you cannot resolve an error, submit a support request with:

• Full request and response payloads.
• Steps to reproduce.
• Error description.

In the ATS, when an employer makes a change in status of an Indeed candidate, the ATS transmits the new status signal, along with an anonymized application ID and a date/time stamp.

The disposition data that Indeed collects from global ATSs is being aggregated and analyzed by the job seeker product team. Disposition data is used to improve targeting of job advertisements and the application experience in order to help candidates better understand how the skills on their resumes meet your requirements.

A great way to encourage client participation in disposition data when they are already opted in is to discuss the importance of moving candidates through the stages within their ATS. For example, after reviewing a CV, change the status to reviewed/screened, and so on.

The statuses will vary depending on your ATS but the most important thing is that Indeed receives as many updates as possible for each of the candidates in the employer's pipeline.

Some of the benefits for clients using continuous stage/status updates might be:

• Employers help Indeed provide better matched candidates in the future.
• Employers can quickly identify which roles they do/do not have enough candidates for. This allows the client to shift focus and budget to roles that are struggling.
• Employers can get a better understanding of hiring timelines from analyzing how long each stage of the process typically takes.

Indeed defines quality signals as those beyond just that of NEW, INCOMPLETE and UNABLE_TO_MAP. To be eligible for tiered status, an ATS must have a minimum quality signal adoption rate of 55%.

Indeed measures an ATS's disposition adoption rate by the number of Indeed Applyable jobs that are sending disposition signals back to Indeed. If all of your clients are opted-in to Indeed Apply, and the ATS sends Indeed confirmation of receipt of applicants, then you would have a 100% disposition adoption rate. If 50% of your clients are opted-in to Indeed Apply, but you are sending disposition signals on all of those jobs, then you would have a disposition adoption rate of 100%.

Indeed understands that ATS partners cannot control how their clients move candidates through the hiring funnel. Disposition Signal adoption rates are measured as the total percentage of Indeed Apply-enabled jobs in which a signal is sent. If Indeed receives confirmation that the job was received by the ATS, that is a signal sent. Indeed encourages partners to map all quality disposition signals, encourage their clients to use them, and automate the release of signals to Indeed after application milestones are achieved to improve the performance of their Indeed Apply integration and build a higher-quality pipeline over time.

Salary and location fields are data nodes that partners can send to Indeed with their clients' jobs. Salary is one of the most important pieces of information according to job seekers.

Job location is one of the most frequently requested details for a job description, and ideally has the most precision possible.

Jobs with salary and precise location perform better. Sponsored indexed jobs with salary and precise location receive:

• 2.5X more impressions per job
• 2.3X more clicks per job
• 3.3X more apply starts per job

Indeed does not provide a sandbox environment. You can read data from Indeed APIs in production with no cost or impact to your account. When testing create and update operations, create test campaigns in a paused state (status=paused) to prevent spending.

See Indexed jobs query format.

To clear an account budget, contact your client success representative.

For XML being crawled on a URL or ATS provided FTP site, Indeed refreshes the job data four times a day every six hours from the time of the last request. For Indeed hosted FTPs, Indeed refreshes the XML feed when a new file is received up to every two hours. If more frequent file uploads occur, previous runs can stop and prevent job updates from occurring.

You can include any fields you like (such as <job_type>, <branch_id>) as long as the standard fields are present.

Visibility in search results is based on Indeed's visibility rules. The Search Quality team prioritizes jobs that are legitimate, unique, have detailed descriptions and locations, and are easy to apply to. Jobs that do not meet these criteria may be hidden from search results. Verify your clients follow the Job Posting Standards for posting. If clients have issues finding their jobs on Indeed, they can reach out to Indeed for assistance.

Indeed requires a URL that points to the job description (not apply page), for these reasons:

• If Indeed Apply fails, Indeed directs the job seeker back to the job URL.
• If a client opts out of Indeed Apply, job seekers need a method to apply.
• The aggregation engine needs an active URL to confirm job content and job activity.

Provide the job in every language you currently have it as a unique job in the XML. If you duplicate the reference number in the XML, only the first appearance of the job appears on Indeed.

Provide the job in every location where there is an open position. Region-wide postings that are not region-wide jobs are rejected for organic visibility on Indeed. Each job needs its own unique location, unique reference number, and should represent a unique job, otherwise it loses visibility on Indeed.

Indeed requires city, state/province, country, and postal code elements. If these elements are not provided, the job does not receive organic visibility by default.

If you have legitimate region-wide postings or remote work opportunities, include them in the file and have your clients request organic visibility. If your client has an Indeed account, they can log in to get support. Clients without an account can submit questions to Indeed directly by visiting the Indeed website.

For companies that are new to Indeed, or for new job sources from companies already on Indeed, Indeed requires a contact email address to verify the account and enable organic syndication. In some cases the email address is not used, but it is required for all jobs.

Remove all <job> elements for the client's jobs from the XML. Clients cannot opt out job by job and must completely opt out of distribution to Indeed. If a discrepancy in job volume between the XML and a client's job portal appears, the source with the largest job volume is preferred for accuracy.

Include the <remotetype> element and indicate one of these options:

• Fully remote
• Hybrid remote
• WFH Flexible (US only)

To be considered "fully remote," include one of these phrases: "This is a remote position," "Employees work remotely," or "Remote work allowed."

To be considered as having "work from home flexibility," include one of these phrases: "Flexible work from home options available," "Work from home days possible," or "Options for working from home."

To post remote jobs, use the elements that Indeed uses to capture location data: <city>, <state>, <country>, and <postalcode>.

To post a remote job in the US, set <city> to "Remote" and leave <state> and <postalcode> blank. Otherwise, the job does not post as a remote position.

All job postings indices use February 1, 2020 as the baseline (= 100). This baseline ensures consistent comparison across countries and time periods.

Seasonally adjusted (SA) indices remove typical seasonal patterns to show underlying trends. Non-seasonally adjusted (NSA) indices show raw data including normal seasonal fluctuations like holiday hiring.

• Job postings and remote work data: Updated daily
• Wage growth data: Updated monthly
• AI job postings data: Updated daily

Coverage varies by dataset. Use the findHiringLabCountriesPublic query to see available countries for each dataset and granularity level.

To get historical data, use cursor-based pagination. Start with your desired filters and use the after parameter and cursor values from previous responses to paginate through results.

The maximum number of results per request is 50. Use pagination to get larger datasets.

The API returns data in chronological order. To filter to a desired time range, use pagination and the date field in your application logic.

Yes. Use the filtering options to view jobs by company, date, or status.

Access is limited to partners in Japan with Job Sync integrations. If you believe you should have access, contact your Indeed representative.

Rejected in the Data viewer means the job was received but failed moderation.

Contact your Client Success team for guidance. The Data viewer does not display specific rejection reasons.

Switching the integration type changes which jobs are rejected, because moderation rules differ between Indeed and Indeed PLUS. A job may be rejected for Indeed PLUS and accepted for Indeed. In such cases, the job may display on the Indeed website but will not be eligible for Indeed PLUS features.

No, the Data viewer does not show expired jobs.

No. Data viewer shows only the moderation status of the jobs you posted successfully.

Indeed builds technical partnerships to deliver seamless and secure hiring solutions across platforms. Learn more and complete the form on the partners page to tell us about your partnership goals.

Indeed is actively working to expand capacity. Provide your company's estimated annual job volume so Indeed can prioritize your integration request. Indeed follows up at the email address provided when next steps are available.

The program refreshes annually every June. Partners must submit proof of eligibility through the Google Form attached in the program announcement email. Tiered partners are updated annually, based on the most up-to-date status of their Indeed integrations. After initial launch, adoption criteria must be met for two consecutive quarters and maintained at that rate throughout the program year.

Qualifying partners are notified via email in June, before publication of the tiered partners in July on indeed.com.

All integrated partners receive technical support for their integrations with Indeed. Indeed provides onboarding and integration launch support to Silver Tier partners, and a dedicated partner manager to Platinum partners. To receive a dedicated partner manager, partners need to meet the criteria outlined in the Platinum Tier.

Dedicated partner management is not required to deliver a highly impactful integration to shared customers.

Currently, only ATS platforms can participate in this program. All ATS partners, exclusive of Japanese companies, can qualify for the tiering program if they meet the designated criteria, regardless of their country of operation. Indeed has a Japanese-specific tiering program for those regional partners.

Indeed provides integration support to all partners through the Integrations Delivery team. While tiered partners receive priority technical support, all partners can receive support by navigating to the support form in Partner Console.

Partners receive a warning after one quarter of not meeting the adoption rate. If improvement is not seen, partners risk losing their tier benefit after the second consecutive quarter of non-qualification.

Active integrations must continue to be serviceable throughout the program year. Partners must update integrations according to Indeed's product release or update schedule. Partners failing to maintain their integration at any time risk losing their tier benefits. Partners placed on Feed Source Approval (FSA) are at risk of losing their tiered status.

The annual deadline to meet the Partner Program criteria is June 1. To be eligible for tiering, you must have met the deadline for Indeed Apply compliance.

Deadline	Requirement
April 1	Indeed Apply Policy for all partners. Indeed Apply integrations are required to have: Screener questions, Equal Employment Opportunity (EEO) questions (for US jobs), and Disposition Sync capabilities.
June 1	Achieve tiered status. See the Partner Program requirements.

For partners who commit to migrating to the Job Sync API to achieve Gold or Platinum status, the deadline to complete development work and go live is October 1. If a partner commits to launching to achieve tiered status and does not go live by October 1, they lose their tiered status.

The information shared from the job seeker profile with the employer via Indeed Apply Sync includes:

• Real email address: The actual email address of the job seeker is shared when they apply through Indeed Apply Sync for indexed jobs.
• Candidate information: This encompasses the job seeker's name, phone number, location, resume, and any responses to screener questions and EEO questions (when applicable).
• Application data: The complete application data is sent back to the employer's applicant tracking system (ATS), which includes all required information for processing the application.

Certain information is excluded from this sharing:

• Dremr alias: For hosted jobs, a Dremr alias is used instead of the real email address.
• Additional data: Employers may want to collect more detailed information (like specific location data) that is not included in the standard sharing process.

Feedback data collected through Disposition Sync is used exclusively to enhance Indeed's matching algorithms and improve hiring performance for clients. This data is not used for any other purposes and is retained only within legal and compliance obligations.

• Short-term use: The data helps refine job recommendations, optimize candidate-employer connections, and provide real-time insights into hiring outcomes.
• Long-term use: Over time, aggregated data contributes to continuous improvements in AI-driven models, ensuring better hiring efficiency and relevance for employers and job seekers.

Indeed processes, stores, and uses Disposition Sync data strictly in accordance with privacy policies and legal obligations.

• Processing and use: The data is used exclusively to enhance job matching algorithms, improve hiring performance for clients, and provide insights into applicant progress. It is not used for any other purposes beyond these stated objectives.
• Storage and security: Data is stored securely and retained only for as long as necessary to fulfill these functions while complying with all applicable legal and regulatory requirements.
• Data sharing: Indeed does not share Disposition Sync data with other entities or third parties, except as required by law or explicitly outlined in privacy policies.

For full details on how Indeed handles data, see:

• Indeed Privacy FAQ
• Indeed API Data Protection Addendum

Indeed tracks the usage of APIs as outlined in the Developer Agreement Terms: Indeed Developer Agreement. Additionally, Indeed requests disposition signals from partners to enhance job matching capabilities and improve hiring outcomes.

Not at this time.

Indeed's Privacy Policy (for example section 4, Purposes, Uses and Disclosures of Information) details the ways in which Indeed processes personal data and the purposes of such processing. This includes using data to improve Indeed products, determine user preferences, help detect fraudulent activity, and for certain marketing purposes. The Developer Agreement covers this.

Yes, disposition statuses are anonymized and securely processed to safeguard privacy. Indeed implements strict data protection measures to ensure compliance with privacy laws and maintain the security of all tracked data.

Indeed retains personal data to the extent necessary in relation to the purposes for which the data are collected or processed, which are communicated in the Privacy Policy, or where necessary for compliance with a legal obligation. Where the personal data Indeed stores no longer needs to be stored, Indeed deletes such personal data, subject to applicable legal requirements.

Indeed uses industry-standard security measures seeking to protect against unauthorized access, disclosure, destruction, and accidental loss of personal data under Indeed's control. The practices Indeed follows vary depending on the nature of the data, the context of the processing, and the risks involved, as well as available technology. See the Indeed Trust Center for more information.

Clients using an ATS that is Indeed Apply compliant have the option to opt-out of sending Indeed disposition signals. This opt-out is done via the ATS. If a Direct Employer owns their own feed and does not wish to share signals with Indeed, they can opt-out of building the Disposition Sync integration.

No. If you use the Indeed Apply Sync integration, you are required to develop Disposition Sync or you are at risk of losing Indeed Apply.

To determine whether you are an eligible ATS to integrate with Indeed, review the Applicant tracking system (ATS) guidelines.

Related:How do I get a signed Developer Agreement?

For terms of service, privacy, and data management policies, see Terms of Service.

To access Indeed's policies, see Policies.

The Developer Agreement is established when your company applies to become an Indeed partner. Submit your integration request through Become an Indeed partner. Indeed reviews your application, vets the integration build, and provides the Developer Agreement to sign as part of onboarding. Review the Indeed Developer Agreement before you start.

Related:For partners with existing agency agreements, how does the Developer Agreement relate?·Why does the Developer Terms of Service require linking to separate documentation?·What makes a company eligible for technical partnership?

The agency agreement is separate from the Developer Agreement, which grants access to Indeed's Public API under different terms. These two agreements serve distinct purposes and are independent of each other, with the agency agreement governing the broader relationship and the Developer Agreement specifically addressing access and use of the API.

Related:How do I get a signed Developer Agreement?

Terms and conditions and technical documents remain online to ensure Indeed can update them if laws or technical requirements change. Any material changes are agreed between the parties.

Related:How do I get a signed Developer Agreement?

Log in to Partner Console with your Indeed user account. On the Dashboard, select your app in the Apps list. The Credentials tab on the app details page lists your OAuth credentials: a client ID and secret.

All partners can receive support by navigating to the support form in Partner Console. Tiered partners receive priority technical support.

Indeed uses automated crawlers to discover and index jobs from public websites. The two Indeed crawlers are Indeedbot (general job indexing) and Indeedshopbot (retail job indexing). For technical details about user agents, IP ranges, and how to allow or block these crawlers, see About Indeed crawlers.

 

Was this page helpful?