Job Posting - Developer FAQs

Please reference Job Posting documentation

• If a customer is using Job Wrapping and Premium Job Posting API, there could be a risk that these jobs are duplicated.
• Between Basic and promoted jobs, our system prioritizes jobs that are promoted.
• It is recommended that customer uses either API or XML Feed based jobs to avoid duplication

You can RENEW only an open job. If the Job is CLOSED, a new request for the job needs to be sent with jobPostingOperationType: CREATE

This is dependent on the HTML tags being provided. To know what HTML tags are supported please refer to these API documentation

Please refer to the following help center article

It depends on the integration.

• For the partners who have integrated with LinkedIn's Apply Connect program, the promoted jobs posted via /simpleJobPosting API will close out existing scraped and wrapped jobs
• For the remaining partners, whichever job was posted first will stay up. If a job is posted via Job Wrapping first, the Simple Job Posting (SJP) job does not post if it has the same unique partner identifier. In such cases, the task status response outlines the following error message:
  • "Trying to create a job with the same partnerIdentifier already exists! Dropping the duplicate job posting creation request. JobId: 123456789, partnerIdentifier: {partner=urn:li:jobPostingPartner:{id}, partnerJobCode=Test123456}."

No, if you have used your job slots you will receive an error message indicating that there are none remaining. You are unable to replace to backfill jobs

Answer: We do not have a utility tool or an API that can help validate a location match. However, refer to the Help Article for few guidelines to ensure improved accuracy for location matching.

Yes, they are supported by all types of PJP contracts, and each multiplexed job takes up an additional slot for job slots. For FP4P, customer will need to set separate budgets for each job.

For jobs with alternateLocations, we will mirror career site experience and provide application back to original jobpostingID. If customer is trying to tie applicants to specific cities, customer should include a question in application flow to capture preferred location.

There should not be a performance difference.

Please refer to this Help Article

• A customer needs to manually provide these details and the partner ATS should provide support to take both LinkedIn Contract ID and Company ID as input.
• Dependent on ATS / Job Distributor this may be done through the UI or manually through support teams
• Below Help Article links can be shared to help customers find their Contract and Company ID:
  • For Contract ID refer to this help center
  • For Company ID refer to this help center

Ensuring the right format of the location details are outlined here

• In order to troubleshoot this issue please collect the following information from the customer:
  • Request Headers, Request Body, Response Headers & Response Body to be shared for both Job Posting and Job Task Status API
  • Submit ticket to GCO support
• Few scenarios why this may happen are:
  • Job got marked as Spam
  • Job Poster User is marked as Spam

Customers can achieve this by setting the ‘workplaceTypes’ field as remote. For more details refer to Job Posting API Schema

Yes, please refer to the following help center article

Yes, please refer to the following API documentation

Yes, please refer to the following API documentation

In this case, you need to check if the application is created or not using uniqueForeignId, if the application is not created you can request it again with the same uniqueForeignId otherwise you need to create a new application with a new uniqueForeignId.

Provisioning APIs allow partners to update customer applications, This will override the existing list of JavaScript SDK domain names with the list of domains in the request body of this POST call.

You can ask customers to opt in again with the widget. Unless "update customer integration" call goes through API job postings will not be active for customers.

• If you are able to post to LinkedIn and can find the location on Bing Geo, you should be able to post via the API
• If there is a valid location not mapping properly, we can map it to post if it is valid. Please reach out to LinkedIn Customer Support ltsatsintegrations@linkedin.com for the same
• We cannot create custom mapping; the client must supply the right location info/string

• In such cases, the task status response outlines this error message: "Caller is not authorized to access the jobs for contract: urn:li:contract:189990
• Troubleshooting steps will be
  • Ensure Customer has configured Job Poster correctly. Refer to Help Article
  • Ensure poster email is the primary email on LinkedIn profile and seat holder on the above contract
  • Admin should check if the default poster is a valid seat holder (sometimes this is not updated if someone is removed from the Recruiter dashboard)

• This issue may arise when customers are manually posting jobs in Recruiter or using Job Wrapping while also using a Job Posting Partner
• An admin can check job slot availability within the Recruiter dashboard product settings
• Please refer to the following help center article

If the Partner has questions on the integration, please ask them to reach out to Zendesk partner support platform and copy to their LinkedIn Business Development and Partner Engineering point of contact directly.

As an admin, you can determine how job slots are allocated across your recruiting team. Click here to learn more about managing job slots and the ability to disable manual job posting for users.

Yes, this is possible. Ensure that your ATS is integrated with LinkedIn’s Premium Job Posting program and then follow the steps mentioned in the article here. To disable the functionality, select the Do not allow manual job postings option.

If the default job poster is removed from the contract after widget integration, Job postings via API will fail until you go through the widget opt-in process to select a new default job poster again.