Chargement de la page…
Elige el feed que proporcione los campos necesarios con una actualización trazable y una reanudación segura, no el que tenga el nombre más moderno. Un CSV completo depositado cada día puede ser preferible a una API sin marca de tiempo ni paginación fiable. Una API resulta interesante para cambios frecuentes y consultas específicas; XML es adecuado para estructuras anidadas y documentadas; FTP es un canal de transferencia, a menudo usado para depositar archivos, no un formato de catálogo. Antes de decidir, prueba la documentación, el volumen, los límites, los identificadores, el precio, el stock, la seguridad y el comportamiento en caso de interrupción.
Separar el formato, el transporte y el contrato de acceso
CSV y XML describen principalmente una representación de datos. HTTP y FTP describen mecanismos de intercambio. Una «API JSON» suele combinar un contrato de aplicación, documentos JSON y un transporte HTTP. Un «feed FTP» puede contener un CSV, un XML, un archivo comprimido o varios archivos. Mezclar estos niveles conduce a comparaciones falsas.
La RFC 4180 documenta un formato CSV de uso común y su tipo MIME. Describe en particular las líneas, los separadores y el escapado de campos entre comillas, pero no define las columnas price, stock o ean. La recomendación XML del W3C define la sintaxis y la buena formación de los documentos XML; tampoco proporciona el esquema de negocio del proveedor. En ambos casos, la documentación del emisor sigue siendo indispensable.
FTP, normalizado históricamente por la RFC 959 y complementado por actualizaciones posteriores, sirve para transferir archivos entre hosts. Su existencia no significa que la conexión esté cifrada ni que el contenido sea reciente. Hay que verificar el protocolo realmente ofrecido, el método de autenticación, las protecciones de transporte y la política de rotación de accesos sin exponer ningún secreto en los registros.
Una matriz de elección basada en hechos
| Opción | Fortaleza típica | Riesgo a controlar | Buen caso de uso |
|---|---|---|---|
| CSV | Fácil de archivar, comparar y reproducir | Codificación, separador, columnas planas, archivos completos voluminosos | Exportación periódica estable |
| XML | Estructura jerárquica y esquema posible | Espacios de nombres, documentos mal formados, complejidad de anidación | Productos, variantes y ofertas estructurados |
| API HTTP | Consultas específicas, paginación, actualizaciones frecuentes | Cuotas, autenticación, paginación, versiones, errores parciales | Stock o precio consultados con regularidad |
| Depósito FTP | Entrega automatizada de archivos | Seguridad del canal, archivos incompletos, convención de nombres | Grandes exportaciones planificadas |
Esta matriz no clasifica una tecnología en términos absolutos. Sirve para plantear las preguntas que el proveedor debe documentar. Un feed debe juzgarse por sus pruebas reales: ejemplo de respuesta, diccionario de datos, cadencia anunciada, condiciones de uso, método de reanudación y contacto en caso de incidencia.
Los criterios que realmente deciden
Completitud de negocio
Enumera los campos innegociables antes de discutir tecnología: identificador de producto y de variante, SKU, marca, título, precio, divisa, naturaleza con/sin IVA, stock con su nivel de precisión, unidad de venta, MOQ, incremento de pedido, imagen y marca de tiempo. Usa la cuadrícula de columnas de un catálogo de mayorista para evitar que una demostración técnica oculte la ausencia de un dato esencial.
Actualidad y prueba de cambio
Pregunta si el feed es completo o incremental. Para un archivo completo, busca una fecha de generación y un mecanismo que impida la lectura antes de que termine el depósito. Para una API, documenta la paginación, el orden estable, los cursores y la semántica de las eliminaciones. Los campos HTTP ETag y Last-Modified son validadores definidos por la RFC 9110, pero su presencia y su significado dependen del servidor. No sustituyen una marca de tiempo de negocio del precio o del stock.
El plazo de confianza de precios y stocks debe elegirse según el riesgo comercial. Un catálogo de características puede evolucionar lentamente; una disponibilidad puede cambiar entre dos pedidos. El mismo ciclo no siempre conviene a ambas familias de campos.
Reanudación e idempotencia
Simula una interrupción. ¿Puedes reanudar en la página siguiente sin perder ni duplicar productos? ¿Tiene un archivo un nombre temporal antes de declararse completo? ¿Proporciona una API un identificador y un orden estables? Las actualizaciones deben ser idempotentes: repetir el mismo documento no debe multiplicar las ofertas.
Archiva la huella del contenido aceptado, la fecha de recogida, la URL o el nombre del archivo y la versión del parser. Esta trazabilidad permite entender si una diferencia procede del proveedor o de tu propia transformación.
Seguridad y derechos
No coloques nunca una clave de API en el código, en el CSV generado o en un mensaje de error. Limita los accesos al ámbito necesario y sigue el procedimiento de rotación del proveedor. Verifica también la licencia o las condiciones de uso: un recurso técnicamente accesible no está automáticamente autorizado para su reutilización comercial. La RFC 9309 recuerda además que robots.txt no es una forma de autorización de acceso.
Prueba de selección en nueve pasos
1. Obtener la documentación oficial y las condiciones de uso. 2. Enumerar los campos obligatorios y su definición. 3. Verificar una pequeña muestra que incluya variantes, roturas de stock y valores vacíos. 4. Medir el volumen y entender la paginación o la división de archivos. 5. Identificar frecuencia, marcas de tiempo y señales de cambio. 6. Provocar un error controlado y observar el código, el mensaje y la reanudación. 7. Repetir el mismo extracto para verificar la ausencia de duplicados. 8. Comparar los datos con fichas oficiales autorizadas. 9. Lanzar un lote canario de proveedor antes de aumentar el volumen.
Al final, redacta una ficha de decisión con tres columnas: «demostrado», «no proporcionado» y «por confirmar». El término «compatible» solo debe usarse si una prueba o una documentación oficial lo demuestra.
Checklist de conexión
- Formato y transporte están identificados por separado.
- El esquema de negocio y las unidades están documentados.
- Se han probado la paginación, las cuotas y el volumen.
- La marca de tiempo de generación está disponible o marcada como ausente.
- Se ha verificado una reanudación tras una interrupción.
- Las eliminaciones y roturas de stock tienen una semántica clara.
- Los secretos permanecen fuera de archivos y registros.
- Las condiciones autorizan el uso previsto.
- Las respuestas brutas y sus huellas están archivadas.
- El canario pasa antes de la importación completa.
Lo que ArbitragePro+ puede automatizar / lo que el vendedor debe verificar
La especificación propuesta diagnostic-flux podría controlar la estructura, los tipos, la paginación, la estabilidad de los identificadores, las huellas y los errores de un canario. Podría comparar los campos proporcionados con los requisitos declarados, sin pretender definir el contrato del proveedor.
El vendedor debe elegir la fuente autorizada, obtener los accesos, confirmar la base fiscal y las unidades, evaluar la seguridad del canal y validar después que la frecuencia se ajusta a su modelo de pedido.
Identificar la conexión adecuada
Consultar las fuentes seguidas por ArbitragePro+ para examinar la información disponible sobre cada conexión.
Fuentes oficiales
- IETF, RFC 4180, «Common Format and MIME Type for CSV Files», https://www.rfc-editor.org/info/rfc4180/ — consultado el 2026-08-17.
- W3C, «Extensible Markup Language (XML) 1.0», https://www.w3.org/TR/xml/ — consultado el 2026-08-17.
- IETF, RFC 9110, «HTTP Semantics», https://www.rfc-editor.org/rfc/rfc9110.html — consultado el 2026-08-17.
- IETF, RFC 959, «File Transfer Protocol», https://www.rfc-editor.org/info/rfc959/ — consultado el 2026-08-17.
- IETF, RFC 9309, «Robots Exclusion Protocol», https://www.rfc-editor.org/rfc/rfc9309.html — consultado el 2026-08-17.