Por qué el campo lifecycleState de LinkedIn solo acepta PUBLISHED al crear

¿Qué hace el campo lifecycleState de LinkedIn en la Posts API?

En la Posts API, el campo lifecycleState de LinkedIn fija el estado de una publicación, y al crearla solo admite un valor: PUBLISHED. El esquema de la Post API en Microsoft Learn lo dice en una línea: "PUBLISHED is the only accepted field during creation." El esquema marca el campo como Enum string y required, así que tampoco puedes omitirlo.

Todas las solicitudes de ejemplo de la página de la Posts API llevan la misma línea:

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

Una creación correcta devuelve 201, y LinkedIn pone el ID de la nueva publicación en la cabecera de respuesta x-restli-id como urn:li:share:{id} o urn:li:ugcPost:{id}.

¿Qué valores puede devolver lifecycleState?

LinkedIn documenta cuatro valores, y tres de ellos solo los vas a leer, nunca a enviar.

El esquema presenta los tres últimos con una salvedad clara: "The following values can be returned in responses." Describen publicaciones, no son instrucciones para LinkedIn.

PUBLISH_REQUESTED es el que confunde a las integraciones. LinkedIn dice que el contenido en ese estado "will be published asynchronously once the processing has successfully completed." Un 201 al crear te dice que LinkedIn aceptó la solicitud. El estado te dice si la publicación está en línea, y son dos hechos distintos.

PUBLISH_FAILED tiene una regla de recuperación concreta: "An edit is required in order to re-attempt publishing." Enviar otra vez la misma solicitud de creación produce una segunda publicación, no un reintento de la primera.

¿Se puede crear un borrador de LinkedIn mediante la API?

No. La Posts API no documenta ninguna forma de crear una publicación en DRAFT, y la regla de creación no deja hueco para ello. DRAFT aparece en las respuestas para contenido que solo existe para su autor, pero LinkedIn no explica cómo llega a existir ese contenido ni cómo lo crearía un desarrollador.

LinkedIn tampoco documenta la respuesta exacta que recibes al enviar "lifecycleState": "DRAFT" al crear. Lo más parecido en la tabla de errores es esta fila:

Así que una herramienta de programación que quiera retener una publicación hasta una hora concreta tiene que retenerla en su propio lado y enviar la llamada de creación en ese momento. La API de LinkedIn no ofrece ningún estado de espera en el que apoyarse. Por eso las publicaciones programadas de LinkedIn dejan de funcionar cuando la herramienta que las retiene pierde su token: en el lado de LinkedIn no hay nada esperando a salir.

¿Dónde se contradice la documentación de LinkedIn?

Hay tres puntos en las mismas dos páginas que no cuadran con el enum.

El primero es la nota sobre viewContext en la página de la Posts API. Dice que la vista 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 no es un valor de la Posts API. Pertenece a la antigua API ugcPosts, y el enum de la Posts API tiene PUBLISH_REQUESTED en su lugar.

El segundo está en la tabla de lifecycleStateInfo de la página del esquema. El campo reviewStatus es "Applicable for lifecycle state values of PUBLISH_REQUESTED and PUBLISHED_FAILED only." No existe PUBLISHED_FAILED. El enum lo escribe PUBLISH_FAILED. Si generas tipos a partir de la documentación, usa la grafía del enum.

El tercero es la sección de actualización. LinkedIn incluye lifecycleState entre los únicos campos que puedes cambiar con un PARTIAL_UPDATE, junto a commentary, contentCallToActionLabel, contentLandingPage y adContext. La página no da ningún ejemplo de cómo cambiarlo ni dice qué transiciones están permitidas. La actualización de ejemplo solo toca commentary y contentCallToActionLabel.

¿Cómo se corresponden los estados de la Posts API con los antiguos de ugcPosts?

La Posts API sustituyó a ugcPosts, y la migración de LinkedIn redujo el enum de siete valores a cuatro. El esquema de ugcPosts en Microsoft Learn sigue listando los siete.

Las descripciones coinciden casi palabra por palabra. ugcPosts define PROCESSING como contenido "submitted for publish but is not yet ready for rendering," que es la definición de PUBLISH_REQUESTED en la Posts API con una palabra cambiada.

Dos de los valores eliminados se trasladaron a otro sitio. Borrar ahora es una solicitud DELETE con X-RestLi-Method: DELETE, y LinkedIn dice "Post deletions are idempotent," devolviendo 204 incluso para una publicación que ya no existía. Las ediciones aparecen como un booleano, lifecycleStateInfo.isEditedByAuthor, que según LinkedIn es "Applicable for UserGeneratedContentLifecycleState value of PUBLISHED only."

¿Qué es lifecycleStateInfo?

Es el objeto que acompaña y explica un estado, y LinkedIn lo devuelve al leer. Tiene tres campos:

• contentStatus: "Status for post content," con los valores PENDING, PROCESSING y FAILED. "If processing completes UGC transitions to PUBLISHED and the contentStatus is null."
• reviewStatus: "Review status of the post," con los mismos tres valores, nulo en cuanto la publicación llega a PUBLISHED.
• isEditedByAuthor: por defecto false.

Aquí es donde PROCESSING existe legítimamente en la Posts API. Es un valor de contentStatus y reviewStatus, no de lifecycleState. El código que hace un switch sobre lifecycleState nunca debería esperarlo.

¿Qué cabeceras necesita una llamada de creación?

Cuatro, y LinkedIn indica dos de ellas al principio de la página de la Posts API: "All APIs require the request header Linkedin-Version: {Version in YYYYMM format}" y "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"... }'

La cabecera de versión es la que rompe las compilaciones, porque tiene que tener seis dígitos y la versión tiene que seguir activa. Las reglas de ese valor están en la nota sobre por qué la cabecera LinkedIn-Version debe ir en formato YYYYMM. La página de la Posts API muestra ahora un aviso de que la Marketing Version 202510 "will be sunset on October 15, 2026."

El token también necesita un permiso de publicación. w_member_social publica en nombre del miembro autenticado. w_organization_social publica en una página de empresa y está "Restricted to organizations where the authenticated member has one of the following company page roles: ADMINISTRATOR, DIRECT_SPONSORED_CONTENT_POSTER, CONTENT_ADMIN."

¿Cómo lees el estado actual de una publicación?

Envía un GET a https://api.linkedin.com/rest/posts/{encoded ugcPostUrn|shareUrn} y añade viewContext=AUTHOR si quieres ver estados no publicados. LinkedIn explica que el valor por defecto, READER, "specifies the version of the post that has been published and is viewable to a general audience." Una publicación que sigue en PUBLISH_REQUESTED es justo lo que la vista READER no te va a mostrar.

Las publicaciones con contenido multimedia pasan antes por un paso de subida aparte. LinkedIn dice que una publicación con imagen "requires uploading an image asset to obtain an Image URN (urn:li:image:{id}) for use in the post," y después la llamada de creación hace referencia a ese URN. La nota sobre el URN de imagen de initializeUpload de LinkedIn cubre esa parte del flujo.

Preguntas frecuentes

¿Es obligatorio lifecycleState en la Posts API de LinkedIn?

Sí. El esquema lo marca como required, y la descripción del error MISSING_FIELD lo nombra como uno de los campos que deben estar presentes, junto a author, visibility y distribution.

¿Puedo programar una publicación de LinkedIn creándola como DRAFT?

No. PUBLISHED es el único valor que LinkedIn acepta al crear, así que una publicación programada tiene que esperar en tu propio sistema hasta el momento en que envías la llamada de creación.

¿Qué significa PUBLISH_REQUESTED?

LinkedIn aceptó la publicación pero no ha terminado de procesarla. LinkedIn dice que el contenido "will be published asynchronously once the processing has successfully completed."

¿Cómo reintento una publicación atascada en PUBLISH_FAILED?

Edítala. La definición de LinkedIn dice "An edit is required in order to re-attempt publishing." Crear la publicación de nuevo genera una publicación nueva.

¿Por qué la documentación de LinkedIn menciona PROCESSING y PUBLISHED_FAILED?

Los dos son despistes de la documentación. PROCESSING es un valor de ugcPosts y de contentStatus, y PUBLISHED_FAILED es una errata de PUBLISH_FAILED. Ninguno aparece en el enum lifecycleState de la Posts API.

¿Una publicación borrada vuelve con el estado DELETED?

No. La Posts API no tiene el valor DELETED. Una solicitud DELETE devuelve 204, y LinkedIn dice que borrar de nuevo la misma publicación también devuelve 204.

¿Qué error devuelve LinkedIn si envío DRAFT como lifecycleState?

LinkedIn no documenta la respuesta exacta para ese caso. El error documentado más cercano es 400 INVALID_VALUE_FOR_FIELD, con el mensaje "{field} cannot be set to {value}." LinkedIn recomienda verificar que los valores enum como lifecycleState sean válidos, y al crear el único válido es PUBLISHED.

¿Cómo veo una publicación de LinkedIn que aún no está publicada?

Envía un GET a https://api.linkedin.com/rest/posts/{encoded ugcPostUrn|shareUrn} con viewContext=AUTHOR. La vista predeterminada, READER, solo muestra la versión publicada y visible para un público general. Una publicación en PUBLISH_REQUESTED no aparece ahí.

¿Qué cabeceras necesita una llamada de creación de la Posts API de LinkedIn?

Son obligatorias Linkedin-Version en formato YYYYMM y X-Restli-Protocol-Version: 2.0.0. La solicitud de ejemplo envía además Authorization con un token Bearer y Content-Type: application/json. La versión debe seguir vigente, porque LinkedIn avisa de que la Marketing Version 202510 "will be sunset on October 15, 2026."

¿Qué permiso necesito para publicar en una página de empresa de LinkedIn?

Necesitas w_organization_social. LinkedIn la describe como "Restricted to organizations where the authenticated member has one of the following company page roles: ADMINISTRATOR, DIRECT_SPONSORED_CONTENT_POSTER, CONTENT_ADMIN." Para publicar en nombre del miembro autenticado se usa w_member_social.