Autenticación general: en Seguridad hay un único endpoint para obtener el token usando un usuario de YiQi. Este token se reutiliza en el resto de los módulos enviándolo como Bearer en el header Authorization.
Política de sesión: actualmente no hay refresh token. Cuando el token expira, se debe volver a autenticar con /token.
- Obtén el token desde el módulo Seguridad.
- Ejecuta GetLoginInformation como healthcheck canónico post-login.
- Toma schemaid desde esa respuesta (método primario).
- Elige un módulo desde el índice y abre su Swagger.
- Dentro del Swagger, expande las operaciones por tag.
- Valida los parámetros obligatorios, cuerpos de request y respuestas.
Estructura común de los Swagger: la mayoría de entidades siguen un formato homogéneo (operaciones list/get/create/update/delete, payloads con estructura repetida y respuestas paginadas o de detalle). Si entendés un módulo, la curva de adopción del resto suele ser mucho más rápida.
Para bots y agentes: consumí modules.json para descubrir el catálogo de specs de manera estructurada.
En los Swagger de YiQi, las entidades repiten un patrón de endpoints. Si aprendés el de una entidad, podés reutilizar el mismo enfoque en casi todas.
GET /entidad/search
Búsqueda filtrada por atributos de la entidad. Suele devolver hasta 50 registros máximo por request.
GET /entidad/{id}
Detalle de una instancia puntual. Requiere el id en path.
POST /entidad
Alta de instancia. El body incluye schemaid y un objeto data.
PUT /entidad/{id}
Actualización de instancia existente, con estructura similar al alta.
DELETE /entidad/{id}
Baja lógica/física según comportamiento de la entidad y reglas de negocio.
GET /entidad/smartie
Vista (smartie) paginada. Un smartie es un reporte/vista armado por usuarios sobre la entidad.
POST /entidad/changestate
Cambio de estado de workflow (cuando la entidad maneja estados).
GET|PUT /entidad/file
Descarga/carga de archivos asociados a atributos de tipo archivo.
GET /entidad/report
Descarga de reportes predefinidos (por ejemplo PDFs) para una instancia.
Orden recomendado: ordenar por fecha de modificación descendente para traer primero lo más reciente.
Estrategia de paginado eficiente: paginar desde page=1 y detenerse cuando se alcance la última fecha ya sincronizada por tu proceso.
Objetivo: evitar paginado exhaustivo innecesario, reducir tráfico y proteger el rendimiento general del sistema.
Responsabilidad de uso: el consumo de la API debe realizarse con criterios de eficiencia, control de volumen y frecuencia de llamadas.
Riesgos operativos: un uso intensivo o sin límites puede saturar tráfico, degradar tiempos de respuesta y afectar a otros usuarios.
Cuenta técnica recomendada: utilizar usuarios de API con el menor privilegio posible, otorgando solo permisos estrictamente necesarios.
Riesgo asumido por el integrador: la implementación, su impacto operativo y los riesgos asociados son responsabilidad del usuario que consume la API.
Autenticación, tokens y control de acceso OAuth2.
Ver Swagger ↗Pedidos, facturación, notas de crédito y remitos.
Ver Swagger ↗Depósitos, movimientos, inventarios y ajustes.
Ver Swagger ↗Maestro de terceros, cuentas corrientes y condiciones comerciales.
Ver Swagger ↗Órdenes de compra, recepciones y acuerdos de precios.
Ver Swagger ↗Asientos, mayores y centros de costo.
Ver Swagger ↗Tesorería, bancos, cobranzas y pagos.
Ver Swagger ↗Parámetros generales y catálogos maestros.
Ver Swagger ↗Órdenes de producción, BOM y rutas.
Ver Swagger ↗Oportunidades, actividades y pipeline comercial.
Ver Swagger ↗Gestión de personal, legajos y novedades.
Ver Swagger ↗Punto de venta, tickets y cobranzas en caja.
Ver Swagger ↗Controles, no conformidades y acciones correctivas.
Ver Swagger ↗Operaciones y catálogos del flujo editorial.
Ver Swagger ↗Envío y trazabilidad de mensajes y eventos.
Ver Swagger ↗Configuración transversal y valores del sistema.
Ver Swagger ↗