Pourquoi le champ lifecycleState de LinkedIn n'accepte que PUBLISHED à la création

À quoi sert le champ lifecycleState de LinkedIn dans la Posts API ?

Le champ lifecycleState de LinkedIn définit l'état d'un post, et à la création il ne prend qu'une seule valeur : PUBLISHED. Le schéma de la Post API sur Microsoft Learn le dit en une ligne : « PUBLISHED is the only accepted field during creation. » Le schéma marque le champ comme Enum string et required, donc vous ne pouvez pas non plus l'omettre.

Chaque exemple de requête de la page Posts API contient la même ligne :

{
  "author": "urn:li:organization:5515715",
  "commentary": "Sample text Post",
  "visibility": "PUBLIC",
  "distribution": {
    "feedDistribution": "MAIN_FEED",
    "targetEntities": [],
    "thirdPartyDistributionChannels": []
  },
  "lifecycleState": "PUBLISHED",
  "isReshareDisabledByAuthor": false
}

Une création réussie renvoie 201, et LinkedIn place l'ID du nouveau post dans l'en-tête de réponse x-restli-id sous la forme urn:li:share:{id} ou urn:li:ugcPost:{id}.

Quelles valeurs lifecycleState peut-il renvoyer ?

LinkedIn documente quatre valeurs, et vous n'en lirez jamais trois autrement qu'en réponse, sans jamais les envoyer.

Le schéma présente les trois dernières avec une précision simple : « The following values can be returned in responses. » Elles décrivent des posts, pas des instructions adressées à LinkedIn.

PUBLISH_REQUESTED est celle qui déroute les intégrations. LinkedIn indique que le contenu dans cet état « will be published asynchronously once the processing has successfully completed. » Un 201 à la création vous dit que LinkedIn a accepté la requête. L'état vous dit si le post est en ligne, et ce sont deux faits différents.

PUBLISH_FAILED a une règle de reprise précise : « An edit is required in order to re-attempt publishing. » Renvoyer la même requête de création produit un second post, pas une nouvelle tentative du premier.

Peut-on créer un brouillon LinkedIn via l'API ?

Non. La Posts API ne documente aucun moyen de créer un post en DRAFT, et la règle de création n'en laisse pas la place. DRAFT apparaît dans les réponses pour du contenu qui n'existe que pour son auteur, mais LinkedIn ne dit pas comment ce contenu vient à exister ni comment un développeur pourrait le créer.

LinkedIn ne documente pas non plus la réponse exacte obtenue en envoyant "lifecycleState": "DRAFT" à la création. La correspondance la plus proche dans le tableau des erreurs est cette ligne :

Un outil de planification qui veut retenir un post jusqu'à une heure donnée doit donc le retenir de son côté et envoyer l'appel de création à ce moment-là. L'API de LinkedIn n'offre aucun état d'attente sur lequel s'appuyer. C'est pourquoi les posts LinkedIn programmés cessent de fonctionner quand l'outil qui les retient perd son jeton : rien n'attend du côté de LinkedIn pour être mis en ligne.

Où la documentation de LinkedIn se contredit-elle ?

Trois passages sur les deux mêmes pages ne concordent pas avec l'enum.

Le premier est la note sur viewContext dans la page Posts API. Elle indique que la vue AUTHOR « can be used to retrieve the latest version of a post, which has not yet been published; it can be in a number of possible states such as: PUBLISHED, DRAFT or PROCESSING. » PROCESSING n'est pas une valeur de la Posts API. Elle appartient à l'ancienne API ugcPosts, et l'enum de la Posts API a PUBLISH_REQUESTED à sa place.

Le deuxième se trouve dans le tableau lifecycleStateInfo de la page du schéma. Le champ reviewStatus est « Applicable for lifecycle state values of PUBLISH_REQUESTED and PUBLISHED_FAILED only. » Il n'existe pas de PUBLISHED_FAILED. L'enum l'écrit PUBLISH_FAILED. Si vous générez des types à partir de la documentation, utilisez l'orthographe de l'enum.

Le troisième est la section sur la mise à jour. LinkedIn liste lifecycleState parmi les seuls champs modifiables avec un PARTIAL_UPDATE, à côté de commentary, contentCallToActionLabel, contentLandingPage et adContext. La page ne donne aucun exemple de modification de ce champ et ne dit pas quelles transitions sont permises. L'exemple de mise à jour ne touche que commentary et contentCallToActionLabel.

Comment les états de la Posts API correspondent-ils aux anciens états ugcPosts ?

La Posts API a remplacé ugcPosts, et la migration de LinkedIn a réduit l'enum de sept valeurs à quatre. Le schéma ugcPosts sur Microsoft Learn les liste encore toutes les sept.

Les descriptions concordent presque mot pour mot. ugcPosts définit PROCESSING comme un contenu « submitted for publish but is not yet ready for rendering, » ce qui est la définition de PUBLISH_REQUESTED dans la Posts API à un mot près.

Deux des valeurs abandonnées ont été déplacées ailleurs. La suppression est désormais une requête DELETE avec X-RestLi-Method: DELETE, et LinkedIn indique « Post deletions are idempotent, » en renvoyant 204 même pour un post déjà supprimé. Les modifications apparaissent sous forme de booléen, lifecycleStateInfo.isEditedByAuthor, dont LinkedIn dit qu'il est « Applicable for UserGeneratedContentLifecycleState value of PUBLISHED only. »

Qu'est-ce que lifecycleStateInfo ?

C'est l'objet compagnon qui explique un état, et LinkedIn le renvoie à la lecture. Il comporte trois champs :

• contentStatus : « Status for post content, » avec les valeurs PENDING, PROCESSING et FAILED. « If processing completes UGC transitions to PUBLISHED and the contentStatus is null. »
• reviewStatus : « Review status of the post, » avec les trois mêmes valeurs, null une fois que le post atteint PUBLISHED.
• isEditedByAuthor : vaut false par défaut.

C'est là que PROCESSING a légitimement sa place dans la Posts API. C'est une valeur de contentStatus et de reviewStatus, pas de lifecycleState. Un code qui fait un switch sur lifecycleState ne devrait jamais s'y attendre.

Quels en-têtes un appel de création exige-t-il ?

Quatre, et LinkedIn en énonce deux en haut de la page Posts API : « All APIs require the request header Linkedin-Version: {Version in YYYYMM format} » et « All APIs require the request header X-Restli-Protocol-Version: 2.0.0 ».

curl -X POST 'https://api.linkedin.com/rest/posts' \
  -H 'Authorization: Bearer {INSERT_TOKEN}' \
  -H 'X-Restli-Protocol-Version: 2.0.0' \
  -H 'Linkedin-Version: 202608' \
  -H 'Content-Type: application/json' \
  --data '{ ...body with "lifecycleState": "PUBLISHED"... }'

L'en-tête de version est celui qui casse les builds, parce qu'il doit faire six chiffres et que la version doit encore être active. Les règles de cette valeur sont dans la note sur pourquoi l'en-tête LinkedIn-Version doit être au format YYYYMM. La page Posts API affiche actuellement un avertissement indiquant que la Marketing Version 202510 « will be sunset on October 15, 2026. »

Le jeton a aussi besoin d'une permission de publication. w_member_social publie pour le membre authentifié. w_organization_social publie pour une page entreprise et est « Restricted to organizations where the authenticated member has one of the following company page roles: ADMINISTRATOR, DIRECT_SPONSORED_CONTENT_POSTER, CONTENT_ADMIN. »

Comment lire l'état actuel d'un post ?

Envoyez un GET à https://api.linkedin.com/rest/posts/{encoded ugcPostUrn|shareUrn}, et ajoutez viewContext=AUTHOR si vous voulez voir les états non publiés. LinkedIn explique que la valeur par défaut, READER, « specifies the version of the post that has been published and is viewable to a general audience. » Un post encore en PUBLISH_REQUESTED est précisément le genre de chose que la vue READER ne vous montrera pas.

Les posts avec média passent d'abord par une étape d'upload distincte. LinkedIn indique qu'un post avec une image « requires uploading an image asset to obtain an Image URN (urn:li:image:{id}) for use in the post, » et l'appel de création référence ensuite cet URN. La note sur l'URN d'image renvoyé par initializeUpload de LinkedIn couvre cette partie du flux.

Questions fréquentes

lifecycleState est-il obligatoire dans la Posts API de LinkedIn ?

Oui. Le schéma le marque required, et la description de l'erreur MISSING_FIELD le cite parmi les champs qui doivent être présents, à côté de author, visibility et distribution.

Puis-je programmer un post LinkedIn en le créant comme DRAFT ?

Non. PUBLISHED est la seule valeur que LinkedIn accepte à la création, donc un post programmé doit attendre dans votre propre système jusqu'au moment où vous envoyez l'appel de création.

Que signifie PUBLISH_REQUESTED ?

LinkedIn a accepté le post mais n'a pas fini de le traiter. LinkedIn indique que le contenu « will be published asynchronously once the processing has successfully completed. »

Comment relancer un post bloqué en PUBLISH_FAILED ?

Modifiez-le. La définition de LinkedIn dit « An edit is required in order to re-attempt publishing. » Recréer le post produit un nouveau post.

Pourquoi la documentation de LinkedIn mentionne-t-elle PROCESSING et PUBLISHED_FAILED ?

Ce sont deux erreurs de documentation. PROCESSING est une valeur de ugcPosts et une valeur de contentStatus, et PUBLISHED_FAILED est une faute d'orthographe de PUBLISH_FAILED. Aucune des deux n'apparaît dans l'enum lifecycleState de la Posts API.

Un post supprimé revient-il avec un état DELETED ?

Non. La Posts API n'a pas de valeur DELETED. Une requête DELETE renvoie 204, et LinkedIn indique que les suppressions répétées du même post renvoient aussi 204.

Quelle erreur LinkedIn renvoie-t-il si j'envoie DRAFT comme lifecycleState ?

LinkedIn ne documente pas la réponse exacte pour ce cas. L'erreur documentée la plus proche est 400 INVALID_VALUE_FOR_FIELD, avec le message "{field} cannot be set to {value}." LinkedIn conseille de vérifier que les valeurs d'enum comme lifecycleState sont valides, et à la création la seule valide est PUBLISHED.

Comment voir un post LinkedIn qui n'est pas encore publié ?

Envoyez un GET à https://api.linkedin.com/rest/posts/{encoded ugcPostUrn|shareUrn} avec viewContext=AUTHOR. La vue par défaut, READER, ne montre que la version publiée et visible par un public général. Un post en PUBLISH_REQUESTED n'y apparaît donc pas.

Quels en-têtes un appel de création de la Posts API de LinkedIn exige-t-il ?

Linkedin-Version au format YYYYMM et X-Restli-Protocol-Version: 2.0.0 sont obligatoires. La requête d'exemple envoie aussi Authorization avec un jeton Bearer et Content-Type: application/json. La version doit encore être active, car LinkedIn prévient que la Marketing Version 202510 "will be sunset on October 15, 2026."

Quelle permission faut-il pour publier sur une Page entreprise LinkedIn ?

Il faut w_organization_social. LinkedIn la décrit ainsi : "Restricted to organizations where the authenticated member has one of the following company page roles: ADMINISTRATOR, DIRECT_SPONSORED_CONTENT_POSTER, CONTENT_ADMIN." Pour publier au nom du membre authentifié, w_member_social suffit.