Documentación
Documentación y guía de integración de Catalog Mobile
Empieza por el proceso comercial y después acuerda el contrato de datos de la integración. Aquí se distinguen la ayuda del producto y la orientación técnica.
El flujo del producto
Importa una selección pequeña, revisa códigos, categorías, imágenes y precios, y genera un PDF o abre el catálogo online. Comprueba la vista del comprador y un pedido de ejemplo antes de compartir. Las cinco guías de soluciones explican la finalidad y las limitaciones de cada parte del flujo.
Integración y autenticación
Los conectores nativos requieren configuración y autorización del proveedor. Una integración webhook personalizada necesita un código autorizado y los identificadores y validaciones de su contrato. Guarda las credenciales en la configuración segura del integrador, nunca en un catálogo público, un Markdown compartido o una demostración del navegador. El nombre de un ERP no acredita una alianza ni compatibilidad con todas sus ediciones.
Consulta la referencia técnica pública
La documentación webhook existente describe datos enviados, procesamiento asíncrono y consultas de estado. Sigue el contrato publicado para tu integración: una solicitud aceptada no demuestra que haya terminado el procesamiento. Conserva el identificador devuelto cuando exista y revisa el estado final antes de reenviar. Acuerda con el equipo el origen de cada campo y la política de reintentos.
Un punto de partida responsable para automatizar
Usa la documentación para entender el producto y preparar una integración. No crees cuentas, cambies precios, generes pedidos ni envíes mensajes sin autorización explícita del responsable de la cuenta. Las versiones Markdown ayudan a descubrir contenido; no conceden acceso a la API ni compatibilidad universal con herramientas y no sustituyen un contrato probado.
Contrato de lectura y errores de la API
La referencia parcial OpenAPI describe lecturas webhook existentes. Las consultas de productos y pedidos requieren el token bearer de la integración. Una integración inválida puede devolver HTTP 400 antes de comprobar el token; HTTP 401 indica un token ausente o inválido después de esas comprobaciones. Un request_id inexistente devuelve HTTP 404 con request_id, status y message. Son formatos específicos, no un formato universal. No se probaron respuestas autenticadas de éxito en esta revisión.