Warum LinkedIn lifecycleState beim Erstellen nur PUBLISHED akzeptiert

Was macht LinkedIn lifecycleState in der Posts API?

Das Feld LinkedIn lifecycleState legt den Status eines Posts fest, und beim Erstellen nimmt es genau einen Wert an: PUBLISHED. Das Post-API-Schema auf Microsoft Learn sagt es in einer Zeile: „PUBLISHED is the only accepted field during creation.“ Das Schema kennzeichnet das Feld als Enum string und required, Sie können es also auch nicht weglassen.

Jeder Beispiel-Request auf der Seite zur Posts API enthält dieselbe Zeile:

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

Ein erfolgreicher Create gibt 201 zurück, und LinkedIn legt die ID des neuen Posts im Response-Header x-restli-id als urn:li:share:{id} oder urn:li:ugcPost:{id} ab.

Welche Werte kann lifecycleState zurückgeben?

LinkedIn dokumentiert vier Werte, und drei davon werden Sie immer nur lesen, nie senden.

Das Schema leitet die letzten drei mit einer schlichten Einschränkung ein: „The following values can be returned in responses.“ Sie beschreiben Posts, keine Anweisungen an LinkedIn.

PUBLISH_REQUESTED ist der Wert, der Integrationen verwirrt. LinkedIn sagt, Inhalte in diesem Status „will be published asynchronously once the processing has successfully completed.“ Ein 201 beim Erstellen sagt Ihnen, dass LinkedIn den Request angenommen hat. Der Status sagt Ihnen, ob der Post live ist, und das sind zwei verschiedene Fakten.

PUBLISH_FAILED hat eine eigene Regel für die Wiederherstellung: „An edit is required in order to re-attempt publishing.“ Denselben Create-Request erneut zu senden, erzeugt einen zweiten Post und keinen neuen Versuch für den ersten.

Kann man über die API einen LinkedIn-Entwurf erstellen?

Nein. Die Posts API dokumentiert keinen Weg, einen Post im Status DRAFT zu erstellen, und die Create-Regel lässt keinen Raum dafür. DRAFT taucht in Antworten für Inhalte auf, die nur für ihren Autor existieren, aber LinkedIn sagt nicht, wie solche Inhalte entstehen oder wie ein Entwickler sie erzeugen würde.

LinkedIn dokumentiert auch nicht die genaue Antwort, die Sie bekommen, wenn Sie beim Erstellen "lifecycleState": "DRAFT" senden. Am nächsten kommen diese Zeilen der Fehlertabelle:

Ein Scheduler, der einen Post bis zu einem festen Zeitpunkt zurückhalten will, muss ihn also auf seiner eigenen Seite halten und den Create-Call genau in diesem Moment senden. LinkedIns API bietet keinen geparkten Status, auf den man sich stützen könnte. Deshalb funktionieren geplante LinkedIn-Posts nicht mehr, wenn das Tool, das sie hält, sein Token verliert: Auf LinkedIns Seite wartet nichts darauf, live zu gehen.

Wo widerspricht sich LinkedIns Dokumentation?

An drei Stellen auf denselben zwei Seiten passt die Doku nicht zum Enum.

Die erste ist der Hinweis zu viewContext auf der Seite zur Posts API. Dort heißt es, die Ansicht 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 ist kein Wert der Posts API. Er gehört zur älteren ugcPosts API, und das Enum der Posts API hat an seiner Stelle PUBLISH_REQUESTED.

Die zweite steht in der Tabelle lifecycleStateInfo auf der Schema-Seite. Das Feld reviewStatus ist „Applicable for lifecycle state values of PUBLISH_REQUESTED and PUBLISHED_FAILED only.“ Ein PUBLISHED_FAILED gibt es nicht. Das Enum schreibt es PUBLISH_FAILED. Wenn Sie Typen aus den Docs generieren, nehmen Sie die Schreibweise des Enums.

Die dritte ist der Abschnitt zu Updates. LinkedIn führt lifecycleState unter den einzigen Feldern, die Sie mit einem PARTIAL_UPDATE ändern können, neben commentary, contentCallToActionLabel, contentLandingPage und adContext. Die Seite zeigt kein Beispiel für diese Änderung und sagt nicht, welche Übergänge erlaubt sind. Das Beispiel-Update ändert nur commentary und contentCallToActionLabel.

Wie lassen sich die Status der Posts API den alten ugcPosts-Status zuordnen?

Die Posts API hat ugcPosts abgelöst, und LinkedIns Migration hat das Enum von sieben auf vier Werte gekürzt. Das ugcPosts-Schema auf Microsoft Learn listet noch alle sieben.

Die Beschreibungen decken sich fast Wort für Wort. ugcPosts definiert PROCESSING als Inhalt, der „submitted for publish but is not yet ready for rendering“ ist, also die Definition von PUBLISH_REQUESTED aus der Posts API mit einem geänderten Wort.

Zwei der gestrichenen Werte sind woanders hingewandert. Löschen ist jetzt ein DELETE-Request mit X-RestLi-Method: DELETE, und LinkedIn sagt „Post deletions are idempotent“, mit 204 auch für einen Post, der schon weg war. Bearbeitungen erscheinen als Boolean, lifecycleStateInfo.isEditedByAuthor, laut LinkedIn „Applicable for UserGeneratedContentLifecycleState value of PUBLISHED only.“

Was ist lifecycleStateInfo?

Es ist das Begleitobjekt, das einen Status erklärt, und LinkedIn liefert es beim Lesen mit. Es hat drei Felder:

• contentStatus: „Status for post content“, mit den Werten PENDING, PROCESSING und FAILED. „If processing completes UGC transitions to PUBLISHED and the contentStatus is null.“
• reviewStatus: „Review status of the post“, mit denselben drei Werten, null, sobald der Post PUBLISHED erreicht.
• isEditedByAuthor: standardmäßig false.

Hier hat PROCESSING in der Posts API seinen legitimen Platz. Es ist ein Wert von contentStatus und reviewStatus, nicht von lifecycleState. Code, der auf lifecycleState verzweigt, sollte ihn nie erwarten.

Welche Header braucht ein Create-Call?

Vier, und zwei davon nennt LinkedIn ganz oben auf der Seite zur Posts API: „All APIs require the request header Linkedin-Version: {Version in YYYYMM format}“ und „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"... }'

Der Versions-Header ist der, an dem Builds scheitern, weil er sechs Ziffern haben muss und die Version noch aktiv sein muss. Die Regeln für diesen Wert stehen in der Notiz dazu, warum der LinkedIn-Version-Header YYYYMM sein muss. Die Seite zur Posts API trägt aktuell eine Warnung, dass die Marketing Version 202510 „will be sunset on October 15, 2026.“

Das Token braucht außerdem eine Posting-Berechtigung. w_member_social postet für das authentifizierte Mitglied. w_organization_social postet für eine Unternehmensseite und ist „Restricted to organizations where the authenticated member has one of the following company page roles: ADMINISTRATOR, DIRECT_SPONSORED_CONTENT_POSTER, CONTENT_ADMIN.“

Wie lesen Sie den aktuellen Status eines Posts aus?

Senden Sie einen GET an https://api.linkedin.com/rest/posts/{encoded ugcPostUrn|shareUrn} und hängen Sie viewContext=AUTHOR an, wenn Sie unveröffentlichte Status sehen wollen. LinkedIn erklärt, dass der Standard, READER, „specifies the version of the post that has been published and is viewable to a general audience.“ Ein Post, der noch in PUBLISH_REQUESTED steckt, ist genau das, was Ihnen die Ansicht READER nicht zeigt.

Medien-Posts durchlaufen vorher einen separaten Upload-Schritt. LinkedIn sagt, ein Post mit Bild „requires uploading an image asset to obtain an Image URN (urn:li:image:{id}) for use in the post“, und der Create-Call referenziert dann diese URN. Die Notiz zur LinkedIn-initializeUpload-Image-URN behandelt diesen Teil des Ablaufs.

Häufig gestellte Fragen

Ist lifecycleState in der LinkedIn Posts API Pflicht?

Ja. Das Schema kennzeichnet es als required, und die Beschreibung des Fehlers MISSING_FIELD nennt es als eines der Felder, die vorhanden sein müssen, neben author, visibility und distribution.

Kann ich einen LinkedIn-Post planen, indem ich ihn als DRAFT erstelle?

Nein. PUBLISHED ist der einzige Wert, den LinkedIn beim Erstellen akzeptiert, also muss ein geplanter Post in Ihrem eigenen System warten, bis Sie den Create-Call senden.

Was bedeutet PUBLISH_REQUESTED?

LinkedIn hat den Post angenommen, aber noch nicht fertig verarbeitet. LinkedIn sagt, der Inhalt „will be published asynchronously once the processing has successfully completed.“

Wie wiederhole ich einen Post, der in PUBLISH_FAILED festhängt?

Bearbeiten Sie ihn. LinkedIns Definition sagt „An edit is required in order to re-attempt publishing.“ Den Post erneut zu erstellen, erzeugt einen neuen Post.

Warum erwähnen LinkedIns Docs PROCESSING und PUBLISHED_FAILED?

Beides sind Fehler in der Dokumentation. PROCESSING ist ein ugcPosts-Wert und ein contentStatus-Wert, und PUBLISHED_FAILED ist eine Falschschreibung von PUBLISH_FAILED. Keiner von beiden steht im lifecycleState-Enum der Posts API.

Kommt ein gelöschter Post mit dem Status DELETED zurück?

Nein. Die Posts API hat keinen Wert DELETED. Ein DELETE-Request gibt 204 zurück, und LinkedIn sagt, dass wiederholte Löschungen desselben Posts ebenfalls 204 zurückgeben.

Welchen Fehler liefert LinkedIn, wenn ich DRAFT als lifecycleState sende?

LinkedIn dokumentiert die genaue Antwort für diesen Fall nicht. Der nächstliegende dokumentierte Fehler ist 400 INVALID_VALUE_FOR_FIELD mit der Meldung "{field} cannot be set to {value}." LinkedIn rät, Enum-Werte wie lifecycleState auf Gültigkeit zu prüfen, und beim Erstellen ist der einzig gültige PUBLISHED.

Wie sehe ich einen LinkedIn-Post, der noch nicht veröffentlicht ist?

Senden Sie ein GET an https://api.linkedin.com/rest/posts/{encoded ugcPostUrn|shareUrn} mit viewContext=AUTHOR. Die Standardansicht READER zeigt nur die veröffentlichte Version, die ein allgemeines Publikum sehen kann. Ein Post in PUBLISH_REQUESTED taucht dort deshalb nicht auf.

Welche Header braucht ein Create-Call der LinkedIn Posts API?

Pflicht sind Linkedin-Version im Format YYYYMM und X-Restli-Protocol-Version: 2.0.0. Die Beispielanfrage sendet zusätzlich Authorization mit Bearer-Token und Content-Type: application/json. Die Version muss noch aktiv sein, denn LinkedIn warnt, dass Marketing Version 202510 "will be sunset on October 15, 2026."

Welche Berechtigung brauche ich, um auf einer LinkedIn-Unternehmensseite zu posten?

Sie brauchen w_organization_social. LinkedIn beschreibt sie als "Restricted to organizations where the authenticated member has one of the following company page roles: ADMINISTRATOR, DIRECT_SPONSORED_CONTENT_POSTER, CONTENT_ADMIN." Für Posts im Namen des angemeldeten Mitglieds nehmen Sie w_member_social.