Da de alta un producto en un catálogo, o actualiza uno existente si el cuerpo trae id.
Devuelve el identificador en la red, no el producto.
Optionaladditional_image_urls?: string[]Optionalavailability?: Optionalbrand?: stringOptionalcategory?: stringOptionalcolor?: stringOptionalcondition?: Optionaldescription?: stringOptionalid?: stringOptionalurl?: stringCrea un catálogo y devuelve su identificador, no el catálogo.
El campo de la respuesta se llama product_catalog y lleva una cadena; para ver el resto hay
que volver a pedir catalogs.
UN producto, por su identificador en la red (el de Meta, no un _id de PlanVortex).
El servidor reenviaba ese filtro con un nombre que el SDK no lee, así que nunca llegaba a la red y la llamada moría con un 2000; se arregló el 2026-08-24 y aquí se expone desde la 0.3.0.
La respuesta viene con otra forma que la del listado. Pedir un producto suelto va al nodo
de ese producto, así que la red contesta con el producto y items trae un objeto. Por eso
esto es un método aparte y no un argumento de list: con un objeto no se construye una
página. Se acepta también una lista, que es lo que devolvería un despliegue que envolviera la
respuesta, y coger el primero es mejor que reventar por la forma del sobre.
const product = await pv.products.get(orgId, accountId, "7123456789012345");
Los productos de un catálogo, encadenando páginas.
Corta cuando llega una página más corta que el limit, no cuando llega a total: en esta
lista total vale 0 siempre.
Los productos de un catálogo.
idCatalog es obligatorio de hecho aunque la API lo pinte opcional: sin él la petición falla
con el error 2000. Para pedir un producto por su identificador, get — no es un
argumento de aquí porque la respuesta viene con otra forma.
const { data } = await pv.products.list(orgId, accountId, catalogId, { limit: 50 });
Los catálogos de la cuenta. Es de donde sale el
idCatalogde todo lo demás.totales la longitud de la página, así que nunca dice que haya otra.