Qué podés hacer
La API de La Pyme te permite leer datos operativos, crear operaciones comerciales y consultar reportes sin acceder directo a la base de datos. Los casos principales son:- Consultar clientes, proveedores, productos, depósitos, listas de precios, etiquetas y métodos de pago.
- Registrar compras, ventas, transferencias y movimientos manuales de stock.
- Aplicar ajustes masivos de costos o precios.
- Consultar reportes agrupados de ventas, compras, pagos e inventario.
Primer request
Usá un endpoint de lectura chico para validar credenciales, scopes y formato de respuesta:Las solicitudes a la API aceptan
Authorization: Bearer ... con API keys o tokens OAuth delegados emitidos para clientes públicos.La cuota de la API pública es por organización:
5000 solicitudes por hora y 120 solicitudes por minuto entre todas las credenciales de esa organización.Convenciones
- Las respuestas usan
request_idpara trazabilidad y el status HTTP como señal de éxito o error. - Los errores usan un envelope estructurado con
type,code,message,retryableydetails. - Los objetos de recursos incluyen
objectcomo discriminador de solo lectura, por ejemplo"object": "customer". - Los listados devuelven
has_moreynext_cursor; usá ese valor comocursorpara pedir la siguiente página. - Las escrituras usan payloads de negocio planos: sin
mode, sininput, sinclienty sinmeta. - Las escrituras que pueden crear duplicados aceptan una clave de reintento en el header
Idempotency-Key; cada endpoint indica si es obligatoria u opcional. - Todos los importes monetarios se envían y devuelven en centavos.
Paginación
Los listados devuelven un token para pedir la siguiente página:- Enviá
limitpara controlar el tamaño de página. El máximo es100y el default es50. - Si
has_moreestrue, copiánext_cursory envialo comocursoren la siguiente request. - No mezcles un
cursorcon filtros distintos. Cuando cambian filtros o búsqueda, empezá sincursor. pageno está soportado.- Los resultados se ordenan de forma estable por el criterio del endpoint; si necesitás reconstruir un export grande, guardá el último
next_cursorprocesado.
Idempotencia
Las escrituras que pueden crear duplicados requieren o aceptanIdempotency-Key.
- Obligatoria:
POST /api/v1/purchases,POST /api/v1/sales,POST /api/v1/products,POST /api/v1/products/bulk-adjustments,POST /api/v1/stock-movements,POST /api/v1/purchase-ordersyPOST /api/v1/purchase-orders/{purchase_order_id}/receipts. - Opcional:
POST /api/v1/stock-transfers. - Reutilizá la misma key solo para reintentar la misma operación con el mismo payload.
- Si reutilizás una key con otro payload, la API responde
409 IDEMPOTENCY_CONFLICT. - Cuando una respuesta exitosa viene de un replay, el cuerpo incluye
idempotent_replay: truedentro del recurso de resultado cuando aplica. - Para timeouts de red o respuestas
5xx, reintentá con la misma key. Para errores4xx, corregí el payload antes de enviar una key nueva.
Respuesta de lectura
Respuesta de error
error.details puede incluir:
field: path lógico del campo o header relacionado.code: código estable para ese detalle.message: explicación legible para mostrar o registrar.
Documentos de ventas y compras
Los detalles de ventas y compras informan la disponibilidad del documento sin incluir bytes base64, rutas de Storage ni URLs firmadas durables:- En ventas, el descriptor está en
document.filey puede tener estadoready,pending,failedomissing. - En compras, el descriptor está en
documenty usareadyomissing. - Solo
readyincluye unaurl. Esa ruta es estable, requieresales:readopurchases:ready responde302hacia una URL firmada de cinco minutos. Configurá el cliente para seguir redirects. pdf_pathen compras se conserva deprecado por compatibilidad de V1. No lo uses para descargar; migrá adocument.url.
document.url autenticada es el contrato para integraciones. El destino
firmado del redirect es efímero y no debe guardarse. Los links públicos opacos
/comprobantes/d/{token} enviados por email son credenciales de portador
separadas, y la ruta pública histórica usada por WhatsApp no forma parte del
contrato de la API.
Flujo de creación de compra
- Buscá el proveedor con
GET /api/v1/suppliers. - Buscá productos con
GET /api/v1/products. - Si enviás
products_received: true, obtené el depósito conGET /api/v1/warehouses. - Enviá
POST /api/v1/purchasescon el payload plano y unIdempotency-Key. - Si la compra se crea, revisá
normalized_purchase,projected_effectsywarningsen la respuesta. - Obtené la compra creada con
GET /api/v1/purchases/{purchase_id}.
POST /api/v1/sales sigue la misma regla: payload de negocio plano más un header Idempotency-Key obligatorio. Si querés guardar el ID de tu sistema en la venta, enviá además integration_source e integration_id en el cuerpo; Idempotency-Key solo deduplica reintentos y no se guarda como referencia externa visible. La respuesta devuelve la venta persistida, la venta normalizada, los efectos proyectados y los warnings.POST /api/v1/stock-transfers también usa un payload de negocio plano. Idempotency-Key es opcional: cuando se envía, el servidor puede deduplicar reintentos; cuando se omite, la operación sigue siendo válida pero no tiene protección automática contra repeticiones.Flujo de aumento de costos por proveedor
- Buscá el proveedor con
GET /api/v1/suppliers. - Revisá los productos afectados con
GET /api/v1/products. - Enviá
POST /api/v1/products/bulk-adjustmentscontarget: "cost", el filtrodefault_supplier_idy unIdempotency-Key. - La capability de comercio actualiza costos, recalcula precios base cuando un producto usa pricing automático por margen y registra efectos de sincronización para canales conectados.
Endpoints disponibles
Contactos
GET /api/v1/customersPOST /api/v1/customersGET /api/v1/customers/{customer_id}PUT /api/v1/customers/{customer_id}GET /api/v1/suppliersPOST /api/v1/suppliersGET /api/v1/suppliers/{supplier_id}PUT /api/v1/suppliers/{supplier_id}
Productos y configuración
GET /api/v1/productsPOST /api/v1/productsGET /api/v1/products/metafield-definitionsGET /api/v1/products/{product_id}PUT /api/v1/products/{product_id}PATCH /api/v1/products/{product_id}/metafieldsPOST /api/v1/products/bulk-adjustmentsGET /api/v1/categoriesPOST /api/v1/categoriesGET /api/v1/categories/{category_id}PUT /api/v1/categories/{category_id}GET /api/v1/price-listsPOST /api/v1/price-listsGET /api/v1/price-lists/{price_list_id}PUT /api/v1/price-lists/{price_list_id}
GET /api/v1/products/metafield-definitions, envialos al crear mediante metafields: [{ "key": "MARCA", "value": "vicus" }] y leelos en el detalle como [{ "key": "marca", "value": "Vicus" }]. Los valores son del grupo y se comparten entre variantes; el listado no los incluye.
Para cambios posteriores, PATCH /api/v1/products/{product_id}/metafields usa entries: un string asigna y null borra. No uses string vacío. PUT /api/v1/products/{product_id} rechaza metafields; las etiquetas se administran por su endpoint separado.
Compras y ventas
GET /api/v1/purchasesGET /api/v1/purchases/{purchase_id}GET /api/v1/purchases/{purchase_id}/documentPOST /api/v1/purchasesGET /api/v1/salesPOST /api/v1/salesGET /api/v1/sales/{sale_id}GET /api/v1/sales/{sale_id}/documentGET /api/v1/purchase-ordersPOST /api/v1/purchase-ordersGET /api/v1/purchase-orders/{purchase_order_id}POST /api/v1/purchase-orders/{purchase_order_id}/confirmPOST /api/v1/purchase-orders/{purchase_order_id}/closePOST /api/v1/purchase-orders/{purchase_order_id}/reopenPOST /api/v1/purchase-orders/{purchase_order_id}/receipts
Inventario y ubicaciones
GET /api/v1/inventoryGET /api/v1/inventory/movementsPOST /api/v1/stock-movementsGET /api/v1/stock-transfersPOST /api/v1/stock-transfersGET /api/v1/stock-transfers/{transfer_id}GET /api/v1/warehousesPOST /api/v1/warehousesGET /api/v1/warehouses/{warehouse_id}PUT /api/v1/warehouses/{warehouse_id}
Etiquetas, cobranzas, medios de pago y reportes
GET /api/v1/tagsPOST /api/v1/tagsPATCH /api/v1/tags/{tag_id}POST /api/v1/customers/tags/applyPOST /api/v1/suppliers/tags/applyPOST /api/v1/products/tags/applyPOST /api/v1/sales/tags/applyGET /api/v1/customer-paymentsPOST /api/v1/customer-paymentsGET /api/v1/customer-payments/{payment_id}POST /api/v1/customer-payments/{payment_id}/voidGET /api/v1/supplier-paymentsPOST /api/v1/supplier-paymentsGET /api/v1/supplier-payments/{payment_id}POST /api/v1/supplier-payments/{payment_id}/voidGET /api/v1/payment-methodsPOST /api/v1/payment-methodsGET /api/v1/payment-methods/{payment_method_id}PUT /api/v1/payment-methods/{payment_method_id}GET /api/v1/points-of-salePOST /api/v1/reports/query- ver Reportes
Ejemplo de creación de producto con variantes
Para crear variantes, enviáoptions con entre uno y tres nombres y variants con las combinaciones vendibles. Cada variante debe incluir exactamente un valor para cada opción declarada. Los SKU y las combinaciones no pueden repetirse; el límite es de 250 variantes por request. Los importes están expresados en centavos.
warehouse_stocks dentro de cada variante. Reutilizá la misma Idempotency-Key solamente para reintentar el mismo producto y la misma matriz.
Ejemplo de creación de compra
Ejemplo de aumento masivo de costos
Scopes requeridos
customers:readcustomers:writecategories:readcategories:writesuppliers:readsuppliers:writeproducts:readproducts:writewarehouses:readwarehouses:writepurchases:readpurchases:writesales:readsales:writetransfers:readtransfers:writeprice_lists:readprice_lists:writepayment_methods:readpayment_methods:writereports:read

