Class PublicationsResource

Crea una publicación en una cuenta.

Sin publish_date se envía en esta misma petición y la respuesta ya dice si salió (state: "sended") o si falló y por qué. Con fecha futura queda ready.

const publication = await pv.publications.create(orgId, accountId, {
    social_network: "instagram",
    text: "Nuevo horno, nuevas hogazas",
    files: [upload._id],
    publish_date: new Date("2026-09-01T10:00:00Z"),
});
Copy

En Pinterest el tablero es OBLIGATORIO, y no da error aquí: sin destination, la publicación se crea en withErrors con el 987 y nadie la intenta. Los tableros se leen con accounts.destinations(), y el enlace del pin va en link, no dentro del texto. Pinterest no tiene comentarios que leer por la API, así que sus pins nunca llegan a pv.comments.

const [board] = await pv.accounts.destinations(orgId, pinterestId);
await pv.publications.create(orgId, pinterestId, {
    social_network: "pinterest",
    title: "Hogaza de centeno",
    text: "La receta, paso a paso",
    files: [upload._id],
    destination: { id: board.id, name: board.name },
    link: "https://panaderia.example/centeno",
});
Copy

Una publicación, con sus ficheros y su cuenta ya resueltos.

Una publicación borrada contesta 917, igual que una que nunca existió.

Las publicaciones de una organización, encadenando páginas.

Las publicaciones de una organización.

Las publicaciones de UNA cuenta. Mismos filtros que list.

Lo que hay publicado en el muro de la cuenta según la red, no según PlanVortex: incluye lo que se publicó por fuera.

En X cuesta un crédito por elemento leído, así que el limit es dinero.

Pide las métricas A LA RED, en vivo, y devuelve su desglose crudo.

En X esto cuesta un crédito por lectura. Para pintar una gráfica usa stats, que lee lo ya medido y no cuesta nada.

Borra una publicación y también el post en la red social.

En X borrar cuesta créditos: sin ellos devuelve un 940 en vez de un error genérico.

En Telegram hay una ventana de 48 horas. Pasada, la Bot API se niega a borrar el mensaje sea cual sea el papel del bot, y la respuesta es un 966 con published_date y max_hours en data — así que lo sensato es apagar el botón en vez de ofrecerlo y fallar. El 969 es el otro caso: al bot ya no le dejan borrar ahí. Y un álbum son varios mensajes: se borran todos, o el post quedaría medio publicado en el canal.

Después deja de leerse por id: get contesta 917, y por tanto un segundo remove() también.

Vuelve a intentar una publicación que falló, sin tocar su contenido.

Se reintenta EN LA PETICIÓN, así que la respuesta ya dice si esta vez salió. Cada llamada gasta un reintento aunque vuelva a fallar por el contenido; sólo los créditos de X cortan antes de gastarlo. Una publicación que no está en withErrors devuelve un 949, y agotar el tope, un 950.

La evolución medida de una publicación: una fila por día, más su última medición.

Es lectura pura de lo guardado: mirar la gráfica no llama a la red y no cuesta créditos. Una series vacía es una respuesta válida —recién enviada, o una red sin estadísticas—, no un error. Cada metrics es el ACUMULADO a esa fecha, no el incremento del día.

Cambia una publicación que todavía no ha salido. Una sended devuelve el error 921.

Editar PONE EL CONTADOR DE REINTENTOS A CERO: el contador cuenta intentos de publicar ese contenido, y acabas de cambiarlo. Es además la salida cuando se agotan los tres.

Lo mismo que update, por la ruta que además nombra la cuenta.

La API tiene las dos y las sirve el mismo handler: da igual cuál se llame, y idAccount sólo se usa para comprobar que la cuenta existe y es de esa organización. Existe aquí porque es una ruta pública y quien venga leyendo la documentación la va a buscar; para escribir código nuevo, update.