Preguntas frecuentes

Dos cambios principales: (1) los nombres de campo son limpios y no exponen columnas internas de la base (por ejemplo id_meli → listing_id, app_status → automeli_sync_status como palabra); (2) la paginación es por cursor en todos los endpoints, en lugar de limit + offset. Además v2 agrega el listado del catálogo real y el cambio de estado de sincronización. El detalle está en la guía de migración.

No. v1 sigue funcionando sin cambios y su doc se conserva en /api-docs/v1. Puede adoptar v2 a su ritmo, endpoint por endpoint, ya que ambas versiones conviven bajo distinta base URL (/api/v1 y /api/v2) con las mismas API Keys.

El prefijo lo indica: automeli_live_* es producción, automeli_test_* es sandbox. También lo ve en GET /v2/ping en el campo environment.

Sí, no hay límite. Lo recomendado es una key por integración (ERP, e-commerce, sistema interno). Si una se filtra, revoca solo esa.

No por default. Solo expiran si las creó con un expires_at específico. De todas formas, conviene rotarlas cada 6-12 meses por higiene.

Pida la primera página sin cursor; tome el next_cursor de la respuesta y vuelva a llamar con ?cursor=<next_cursor>. Repita mientras has_more sea true. No cambie los filtros a mitad de la paginación — ver paginación por cursor.

Igual que en la API de Mercado Libre: contar el total en cada página es caro sobre catálogos grandes. Por eso total se calcula sólo en la primera petición (sin cursor) y no se recalcula en las siguientes.

No. Antes de publicar, Automeli compara contra sus publicaciones vivas y contra lo que ya está en cola en otros jobs suyos: en ambos casos el item se marca como duplicate y se salta sin consumir crédito. Sí se vuelve a publicar un SKU cuya publicación anterior fue eliminada, que es justamente lo que se espera.

Porque la categoría fiscal y el tipo de publicación se definen a nivel job, no por producto. Si los productos que promovió tienen categorías fiscales o tipos de publicación distintos, se agrupan y se crea un job por grupo. Cada uno se consulta por separado con GET /v2/products/jobs/{jobId}. Tenga en cuenta el límite de 6 jobs activos.

Para que el contrato sea autoexplicativo y estable: lee enabled, no un 1. Además, la lectura (automeli_sync_status) y la escritura usan el mismo vocabulario, así que son simétricas. El número crudo se rechaza con 422.

Lo más común: su seller no tiene cuenta de prueba conectada y la key es test. El publicador intenta publicar, no encuentra cuenta test y falla. Solución: conecte una cuenta test desde Configuración → Cuenta de Pruebas, o use una key live.

Recibe 429 E_PRODUCT_MAX_CONCURRENT_JOBS. Espere a que termine alguno y reintente. El límite existe para no saturar el publicador.

Sí — es lo recomendado. Lo que NO debe hacer: pegarla en archivos versionados en Git, en URLs/query strings, ni en logs. Si por error queda incluida en un commit, revóquela desde el dashboard y genere una nueva.

Recibe 404 E_ACCOUNT_NOT_FOUND o el job pasa a failed con error_message claro. Antes de publicar, puede chequear con GET /v2/account que ml_connected: true.

Son los tipos de publicación de Mercado Libre, no inventados por Automeli.

• gold_pro (Premium) → mayor visibilidad y opción de cuotas sin interés para el comprador, pero con comisión más alta. Conviene para productos de precio medio/alto donde las cuotas ayudan a vender.
• gold_special (Clásica) → comisión más baja, sin cuotas sin interés. Conviene para productos baratos o de alta rotación donde el precio importa más que las cuotas.

Los tipos gold_premium, gold, silver y bronze son legacy: casi nadie los usa, los aceptamos solo por compatibilidad con cuentas viejas.

Si no envía el campo, en v2 se usa gold_special (Clásica).