Tutoriel API LinkedIn : publier avec l’API Posts

Tutoriel API LinkedIn : publier avec l’API Posts

Comment publier sur LinkedIn via l’API Posts : import d’images et de documents, l’en-tête x-restli-id, et pourquoi les profils personnels et les pages nécessitent deux applications.

Publier sur LinkedIn se résume à un appel POST https://api.linkedin.com/rest/posts, l’URN de la publication créée étant renvoyé dans l’en‑tête de réponse x-restli-id plutôt que dans le corps. Les médias fonctionnent en enregistrant d’abord un import, en téléversant les octets, puis en référençant l’URN renvoyé. Les complications viennent du modèle de permissions et du versionnage mensuel de l’API de LinkedIn.

Que peut publier l’API Posts, et que ne peut‑elle pas publier ?

Pour les publications organiques (non sponsorisées), le tableau des types de contenu de LinkedIn est explicite.

Type de contenuSupport organique
Texte seulOui
ImagesOui
VidéosOui
Documents (PDF, DOC, DOCX, PPT, PPTX)Oui
ArticleOui
MultiImageOui
SondageOui
CarrouselNon, sponsorisé uniquement

Les publications de documents sont la bonne surprise : les carrousels PDF, le format qui performe bien sur LinkedIn, sont entièrement pris en charge via l’API Documents. Les limites sont un fichier d’au plus 100 Mo et 300 pages maximum. Les publications carrousel organiques, au sens publicitaire du terme chez LinkedIn, ne sont pas prises en charge ; l’équivalent organique est MultiImage. Les publications de type Article ne récupèrent pas automatiquement le contenu de l’URL pour vous : vous devez fournir vous‑même le titre, la description et l’URN d’une image miniature.

L’écart structurel se situe dans la répartition des permissions. Publier en tant que personne nécessite w_member_social. Publier en tant que page d’entreprise nécessite w_organization_social, avec r_organization_social pour relire, et le membre authentifié doit détenir un rôle ADMINISTRATOR, CONTENT_ADMIN ou DIRECT_SPONSORED_CONTENT_POSTER sur cette page. En pratique, ce sont des produits API différents avec des demandes d’accès distinctes, ce qui explique pourquoi un outil qui publie à la fois sur un profil et sur une page finit par gérer deux applications LinkedIn séparées. Notre propre intégration fait exactement cela.

Remarque : ces informations ont été vérifiées par rapport à la documentation de l’API Posts, de l’API Images et de l’API Documents de LinkedIn sur Microsoft Learn, à la date de septembre 2026. Les plateformes modifient ces éléments sans préavis.

Comment fonctionne l’authentification, et quelle est la durée de la revue d’accès ?

OAuth à trois étapes pour obtenir un jeton de membre, puis chaque requête porte trois en‑têtes : Authorization: Bearer, X-Restli-Protocol-Version: 2.0.0, et LinkedIn-Version au format YYYYMM. Ce dernier n’est pas optionnel et n’est pas permanent. LinkedIn publie des versions mensuelles et retire les anciennes ; un avis de dépréciation actuellement présent sur la page indique que la version Marketing 202508 sera retirée le 17 août 2026. Une version que vous avez figée l’an dernier devient une panne.

L’accès aux produits de gestion communautaire est accordé par application. LinkedIn ne publie pas de délai de revue dans cette documentation développeur, il faut donc considérer la durée comme inconnue. Notez aussi que r_member_social est une permission restreinte « disponible uniquement pour les utilisateurs approuvés », donc relire les propres publications d’un membre est une demande distincte de celle d’écrire.

Nous n’avons pas pu vérifier les durées de vie des jetons d’accès de LinkedIn à partir des pages de l’API Posts, Images ou Documents, qui ne les indiquent pas. Lisez le chiffre actuel dans la propre documentation d’authentification de LinkedIn plutôt qu’un chiffre tiré d’un article de blog, y compris celui‑ci.

Quelle est la séquence d’appels de publication ?

Pour une publication texte, un seul appel. Pour un média, trois :

  1. POST /rest/images?action=initializeUpload (ou /rest/documents?action=initializeUpload) avec un initializeUploadRequest.owner défini sur l’URN de la personne ou de l’organisation.
  2. Lire uploadUrl et l’URN de l’actif (image ou document) dans l’objet value de la réponse.
  3. Téléverser les octets vers uploadUrl. Un téléversement de document réussi renvoie 201.
  4. POST /rest/posts avec author, commentary, visibility, distribution, lifecycleState: "PUBLISHED", et content.media.id défini sur l’URN de l’actif.
  5. Lire l’URN de la publication créée dans l’en‑tête de réponse x-restli-id du 201. Il n’est pas dans le corps.
# 1. register the upload
curl -X POST 'https://api.linkedin.com/rest/documents?action=initializeUpload' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'X-Restli-Protocol-Version: 2.0.0' -H 'LinkedIn-Version: 202608' \
  -d '{"initializeUploadRequest":{"owner":"urn:li:organization:5515715"}}'
# -> value.uploadUrl, value.document = urn:li:document:...

# 2. upload the bytes
curl -i --upload-file ./deck.pdf -H "Authorization: Bearer $TOKEN" "$UPLOAD_URL"

# 3. create the post, then read x-restli-id from the 201
curl -i -X POST 'https://api.linkedin.com/rest/posts' \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -H 'X-Restli-Protocol-Version: 2.0.0' -H 'LinkedIn-Version: 202608' \
  -d '{
    "author": "urn:li:organization:5515715",
    "commentary": "Our Q3 teardown, 12 pages.",
    "visibility": "PUBLIC",
    "distribution": {"feedDistribution":"MAIN_FEED","targetEntities":[],
                     "thirdPartyDistributionChannels":[]},
    "content": {"media": {"title":"deck.pdf","id":"urn:li:document:..."}},
    "lifecycleState": "PUBLISHED",
    "isReshareDisabledByAuthor": false
  }'

Les actifs ont leur propre champ de statut : WAITING_UPLOAD, PROCESSING, PROCESSING_FAILED ou AVAILABLE. Référencer un actif qui n’a pas atteint AVAILABLE est une cause fréquente de publication envoyée sans son média.

Quelles sont les limites de débit ?

Le tableau des erreurs de l’API Posts de LinkedIn documente 429 TOO_MANY_REQUESTS avec la recommandation de réduire la fréquence des requêtes et de réessayer après un délai, mais la page n’indique aucun chiffre précis par application ou par membre. Nous n’avons pas pu vérifier de chiffres de limitation concrets à partir des pages de l’API Posts, Images ou Documents. LinkedIn publie des limites quotidiennes au niveau de l’application et du membre dans le portail développeur pour votre propre application, qui est la seule source fiable pour votre quota ; lisez‑les donc là plutôt que de supposer un chiffre commun.

Deux limites sont énoncées concrètement et méritent d’être prises en compte dès la conception : les documents sont plafonnés à 100 Mo et 300 pages, et les images doivent faire moins de 36 152 320 pixels, aux formats JPG, GIF ou PNG, les GIF étant plafonnés à 250 images.

Remarque : ces informations ont été vérifiées par rapport à la documentation de l’API Posts, de l’API Images et de l’API Documents de LinkedIn sur Microsoft Learn, à la date de septembre 2026. Les plateformes modifient ces éléments sans préavis.

Qu’est‑ce qui va réellement vous coûter trois semaines ?

Deux applications, deux revues. La publication sur profil personnel et la publication sur page d’entreprise sont des produits distincts avec des approbations distinctes. Si votre produit promet les deux, vous gérez deux flux OAuth, deux jeux d’identifiants et deux processus de revue, et l’un peut être approuvé pendant que l’autre ne l’est pas.

Le versionnage mensuel. LinkedIn-Version a besoin d’un plan : une mise à jour programmée, un test qui exerce la version actuelle, et une personne qui lit les avis de dépréciation. C’est le coût de maintenance que l’on oublie souvent au moment d’estimer le développement.

Le pipeline média. Import en deux étapes pour les images, documents et vidéos, chacun avec son propre point de terminaison et son propre statut d’actif à surveiller, plus une validation du format et de la taille avant de gaspiller un import.

Asynchronisme et échec partiel. Un 201 renvoyé par /rest/posts est la confirmation la plus solide que puisse donner l’une des grandes plateformes, mais l’étape d’actif qui le précède est asynchrone, et lifecycleState peut revenir en PUBLISH_FAILED, nécessitant une modification pour réessayer. Modélisez un état processing, comme expliqué dans notre guide de l’API de planification pour les réseaux sociaux, et ne signalez jamais un succès sur le seul appel de téléversement.

Si vous rédigez aussi le texte, le compteur de caractères LinkedIn montre où tombe la coupure du « voir plus ».

En résumé

  • Un seul appel POST /rest/posts ; l’URN de la publication revient dans x-restli-id, pas dans le corps.
  • Le média nécessite initializeUpload, un téléversement, puis l’URN de l’actif dans content.media.id.
  • Les documents (PDF et fichiers Office) sont pris en charge de façon organique, jusqu’à 100 Mo et 300 pages.
  • Les profils personnels et les pages d’entreprise utilisent des permissions différentes et, en pratique, deux applications.
  • LinkedIn-Version est obligatoire et les versions sont retirées. Programmez les mises à jour.

Faire cela une fois plutôt qu’une fois par plateforme

Si LinkedIn n’est qu’un des nombreux réseaux dont vous avez besoin, le travail par plateforme se multiplie plutôt qu’il ne s’additionne. BulkPublish publie sur 15 plateformes via une seule API REST, y compris les profils personnels et pages d’entreprise LinkedIn (les deux applications, les deux revues, déjà faites) et les publications de documents LinkedIn. Les en‑têtes de version, l’interrogation des actifs et le renouvellement des jetons sont gérés de notre côté, et une publication ciblant plusieurs réseaux affiche partial lorsque l’un d’eux échoue, plutôt que de prétendre avoir réussi. La référence API se trouve sur /developers/ et l’aperçu de l’intégration REST sur /integrations/rest-api/.

À lire aussi