LinkedIn requires all Pay For Performance (P4P) implementations undergo a certification review. This ensures that our customers get the best experience using a LinkedIn partner integration. The technical review and sign off also ensures that there are no gaps in integrations and that partner products keep up with the latest features and updates released by LinkedIn.
As an API partner, please go through the requirements listed below. These are the capabilities that an integrating partner is expected to build in their product. We request you to plan and incorporate these features early in your design. When you are nearing completion, you must initiate a technical sign off request by contacting your LinkedIn Partner Solutions Engineer POC.
A demo will be scheduled during which you will be asked to showcase all your product capabilities. During this evaluation, LinkedIn may suggest modifications which will need to be completed for the sign off. If all criteria are met (as per the envisioned scope), the technical sign-off is awarded.
P4P is an additional feature you can enable on top of LinkedIn Job Posting, so fundamental job posting certification modules will not be assessed. However, we do recommend you go through the basics certification modules to avoid common errors once your integration is up and running. If you are an individual job promotion partner, such as JD or ATS, please go to the section below for For Individual Job Promotion Partner.
For Individual Job Promotion Partner
Module 1 - Onboarding Fundamentals
Rule
API Requirements
Expected Result
JD-001
Demonstrate how you create and maintain each LinkedIn company ID or page URL & child developer application association/mapping of onboarding customers. "Customers" refer to end job requesters.
For better P4P job validation and analytics, we require customers to create their LinkedIn company pages to post jobs for, so the partner must be aware of the concept and host storage of records. One customer account should be represented by one child developer application to post jobs.
JD-002
Demonstrate how you provision and store each child contract ID for the corresponding child developer application.
Mapping and mechanisms of customer/company to customer child contract to understand. This will also show how you enable the P4P of each customer.
JD-003
Demonstrate that a customer can view LinkedIn Jobs Terms and Conditions in a global setting before a job posting is submitted.
Customers can view LinkedIn terms before they submit a job, so they are aware of compliance and liability in keeping valid job content. Note that jobs can be caught in trust reviews which will pause the job campaigns to appeal or be closed.
JD-004
Acknolweldge the exsitence of a "default job poster". In P4P, it is mostly a hidden value that you can overwrite by a job with a field posterEmail.
It is important to have the right person registered as a default poster for Production since any job audit or contract-related notifications that require actions are sent to this email address.
JD-005
Acknolweldge how duplicate jobs work in P4P and LinkedIn Job prodct-wise.
Remember that among different LinkedIn Job products, the jobs with the same Titles, Locations, and Companies (TLCs) will be marked as Duplicate and closed. Within P4P, as far as externalJobPostingId is different, the jobs will not be considered duplicates.
JD-006
Acknolweldge the awareness of LinkedIn Company Shield.
Depending on the customer company, a job posting can be held before processing based on other LinkedIn products they have already subscribed. If this happens and you have a question, you need to reach out to your LinkedIn Business Development contact to unblock.
Module 2 - Job Managing
Rule
API Requirements
Expected Result
JD-007
Demonstrate creating a P4P job from the right child application with a budget amount and currency.
Job created from the correct child application with the correct child contract ID from the provisionedHiringContracts API. Please make sure the companyJobCode has been filled out. Note that listedAt and expireAt are not mutable for P4P jobs.
JD-008
Demonstrate updating a P4P job as it is a request from a customer. You can update any fields for a demo, but we recommend showing updates to location and title, at least.
Job is updated with the new details. Note that you cannot update listedAt, expireAt, and budget for P4P jobs.
JD-009
Demonstrate renewing a P4P job as it is a request from a customer.
Job is renewed and reset with a new budget and 30-day duration.
JD-010
Demonstrate closing a P4P job as it is a request from a customer.
Job is closed. Note that P4P jobs will be automatically closed after 30 days without an extension unless you have renewed with a new budget. A closed job cannot be updated or renewed.
Module 3 - Job Reporting
Rule
API Requirements
Expected Result
JD-011
Demonstrate fetching a daily job report (either one of "By IDs" or "By Date Range") for one customer/child application. If applicable, explain how the fetched data will be displayed to customers.
The report was retrieved and usage was understood. It is okay to use this data only for your internal analysis.
JD-012
If you are using job reports in Production, explains how often job report data is refreshed and job charges are finalized.
The data cut-over rule of the same UTC day and 48-hour charge settling time are understood.
JD-013
Demonstrate fetching a budget report. If applicable, explain how the fetched data will be used.
The report was retrieved and usage was understood. You normally are not expected to display this data to customers.
Module 4 - Job Inline Up/Downgrading (If You Are Applicable)
Rule
API Requirements
Expected Result
JD-014
Demonstrate downgrading a P4P job to Basic job.
Job is downgraded to a free job.
JD-015
Demonstrate upgrading a Basic job to P4P job.
Job is upgraded to a P4P job.
Module 5 - Error Handling
Rule
API Requirements
Expected Result
JD-016
Explain how you will investigate and engage support when API failures occur in Production.
General flow of how you/the partner supports their customers when there are issues is understood. A clear path of escalations is identified to take corrective actions including Linkedin Zendesk filing.
Most failures and update/renewal requests are self-serviceable without reaching out to LinkedIn. These APIs must be accessible to the partner's support team, so they are aware of how to troubleshoot errors.
JD-018
Demonstrate how failed requests are reposted.
Show how you handle retrying or reposting. A failure here does not only include synchronous validation errors but also includes asynchronous errors that require adjusting specific job posting request payloads.
JD-019
Demonstrate how and when system logs are generated for requests.
Full API transactions, including URLs, HTTP headers (X-LI-UUID), requests, and responses should be logged especially when failures happen. You must include as much as information possible when you end up submitting a support ticket to LinkedIn.