SmartQuery
Índice
Agendar demo
A-01 Emisión

El SQL que ya corre en su ERP, emitido como endpoint REST.

La pasarela entre SIESA UnoEE o Siigo Nube y las aplicaciones que necesitan sus datos. Su equipo aporta el script que ya tiene.

Recorrido de una consulta: el script T-SQL entra a la pasarela y sale como respuesta JSON por una ruta REST. Debajo, el detalle de una sentencia que la pasarela rechaza.
Entradaconsulta.sql
SET NOCOUNT ON;

SELECT f200_razon_social
FROM   t200_mm_terceros
WHERE  f200_id = @nit;
Salida200 · application/json
{
  "data": {
    "codigo": 200,
    "mensaje": "Success",
    "data": [
      { "f200_razon_social": "ACME" }
    ]
  }
}
Detalle A · escala 4:1DELETE FROM t200_mm_tercerosRechazadaEscribe sobre una tabla real del ERP. La pasarela la detiene antes de que salga.
GET /api/v1/proxy/execute/{conexión}/terceros-busqueda

Ejemplo ilustrativo. La ruta y la envolvente son las reales.

ProyectoSmartQuery · Pasarela de integración ERP
LáminaA-01 / A-09
Emisión18/09/2026
Revisión01
Aprobado porAgendar demo

WhatsApp +57 304 242 5180Documentación para implementadores

A-02 Conectores

Dos sistemas conectados. Dicho sin redondear.

Un conector es una integración en producción con pruebas, no un logo en una fila. Estos dos existen, tienen pruebas y corren en producción. Lo que no está aquí, no está.

SIESA UnoEE

ERP · En producción

55
consultas en el catálogo
3.213
líneas de SQL a mano
6
colecciones listas

Su equipo pega el script T-SQL que ya usa en sus reportes —con SET NOCOUNT ON, variables y tablas temporales— y marca dónde van los parámetros.

  • Su equipo ejecuta tanto las consultas del catálogo como las que publique después, por la misma ruta versionada y con el mismo contrato de respuesta. Ninguna de ellas escribe sobre una tabla del ERP.
  • La conexión se prueba contra el ERP en vivo antes de quedar guardada: si las credenciales no responden, no queda registrada, y ningún endpoint se publica sobre una conexión que no haya respondido.
  • El registro en el ERP se declara una sola vez y después se consume como un POST más: usted envía JSON y recibe la envolvente única, con la línea rechazada y su motivo cuando el ERP no acepta el documento.
  • Las credenciales del ERP se guardan cifradas con AES-256-GCM, nunca aparecen en una respuesta y nunca salen de su instancia: su proveedor de software integra sin recibirlas.

Siigo Nube

Contable · En producción

67
endpoints en el catálogo
13
módulos cubiertos
2
colecciones listas

Aquí no hay SQL: la operación contra Siigo se declara una vez, con sus parámetros validados, y queda publicada como un endpoint más del catálogo.

  • El catálogo cubre consulta y registro contra Siigo —facturas, notas crédito y comprobantes— sin una línea de SQL de por medio: la operación se declara una vez y su aplicación solo la consume.
  • Usted fija el techo de consumo hacia el proveedor en cada conexión y la pasarela no lo excede. Su equipo no programa esperas ni colas para respetarlo.
  • Cuando el proveedor deja de responder, la pasarela deja de insistir y lo declara en la respuesta: su aplicación distingue un error de su petición de una caída del proveedor, y recibe Retry-After cuando hay una espera que respetar.
  • Una escritura jamás se reintenta automáticamente. Las operaciones que admiten Idempotency-Key lo declaran, y la documentación dice en cuáles no tiene efecto, para que usted decida si repite.
  • Su aplicación nunca autentica contra Siigo ni administra sus tokens: usa una sola credencial, la de SmartQuery, con el alcance que le asignaron.

No emitido

Sin conector hoy. Integrar uno es trabajo acotado y presupuestable sobre la misma plataforma, con el mismo contrato de ejecución y el mismo gobierno — no un desarrollo desde cero ni una instancia distinta.

  • OdooSin driver. Integrable bajo demanda.No emitido
  • SAP Business OneSin driver. Integrable bajo demanda.No emitido

Solicitar un conector para su ERP

A-03 Guard SQL

No prohíbe palabras. Mira sobre qué objeto escribe la sentencia.

Una lista de palabras prohibidas bloquea un INSERT legítimo contra una tabla temporal y deja pasar cualquier rodeo. El análisis de SmartQuery resuelve el objeto de destino de cada sentencia y decide sobre eso. En la referencia técnica estácómo se evalúa cada sentencia antes de ejecutarla.

Detalle · destinoEscala 4:1
Aceptada
INSERT INTO #saldos_tmp
SELECT f200_nit, SUM(f350_valor)
FROM t350_co_docto_contable
GROUP BY f200_nit

#saldos_tmpTrabaja sobre una tabla temporal del propio informe. No toca el ERP: se ejecuta.

Rechazada
DELETE FROM t200_mm_terceros
WHERE f200_id = @nit

t200_mm_tercerosEscribe sobre una tabla real del ERP. La pasarela la detiene antes de que salga.

3
Validaciones por consulta

Al publicar el endpoint, al recibir la petición y al ejecutar con sus valores ya puestos: un parámetro no puede colar una escritura que el endpoint no tenía.

0
Excepciones

El análisis corre en toda ruta que pueda registrar algo en el ERP, para todos los perfiles.

DELETE · DROP · TRUNCATE · ALTER
Bloqueadas para todos

Sin excepción de rol y sin excepción de endpoint. Ninguna configuración del cliente ni ningún parámetro las habilita.

A-05 Gobierno

Un endpoint no se publica. Se aprueba.

El ciclo de vida tiene 5 estados y solo dos de ellos responden. Un endpoint en borrador o rechazado existe en el catálogo y no ejecuta: la aprobación no es una etiqueta, es la condición para que la ruta conteste.

Tabla de revisionesEjecutan: Aprobado · Activo
  1. 01BorradorEl usuario del cliente lo escribe.No ejecuta
  2. 02En revisiónLo envía a aprobación.No ejecuta
  3. 03AprobadoQueda firmado tras la revisión. Ejecuta.Ejecuta
  4. 04ActivoEn servicio. Ejecuta.Ejecuta
  5. 05ObsoletoSe retira con encabezados RFC 8594 y enlace a su sucesor.No ejecuta

El retiro se anuncia en la propia respuesta. Un endpoint obsoleto viaja con encabezados RFC 8594: fecha de retiro y enlace a su sucesor, antes de dejar de responder.

Quién puede qué

El alcance se verifica en el servidor en cada petición, no se insinúa escondiendo opciones en la interfaz. Un perfil no puede ejecutar lo que no heredó, ni siquiera llamando la ruta directamente.

  • Administración de la plataformaLa parametrización del ERP la ejecuta SmartQuery. Ningún cliente y ningún tercero recibe un perfil capaz de hacerla.
  • Administración delegada del clienteEl cliente gestiona los usuarios y los permisos de su propio equipo sin escalar a soporte.
  • ConsumoUsa el catálogo que le asignaron, lo prueba contra una conexión real y administra sus propias llaves.
  • Integrador externoSolo lectura sobre lo que se le asignó, con alcance heredado y un cupo acotado de llaves activas.
A-06 Operación

Lo que pasa entre la petición y su ERP.

Una pasarela no es solo un conector. Esto es lo que se interpone entre una aplicación cualquiera y la base de datos de su ERP, y es lo que evita que la conveniencia de hoy sea el incidente del año que viene.

Recorrido de una petición por la plataforma: entra por el borde, donde se aplican el límite de tasa y la mitigación de abuso; pasa por la pasarela, que autentica, resuelve alcances y analiza toda escritura; consulta la caché, que puede responder sin llegar al ERP; y solo entonces llega al ERP. Cada ejecución se registra en paralelo.
Su aplicación

Una petición HTTP con su API key.

Borde
  • Límite de tasa
  • Mitigación de abuso

Delante de su instancia. El tráfico se acota antes de llegar a ella.

Pasarela
  • Autenticación y alcance
  • Roles heredados
  • Análisis de escritura

Resuelve sobre qué objeto escribe cada sentencia y detiene la que toca el ERP.

Caché
  • TTL propio por endpoint
  • Solo lecturas

Alcance por usuario, conexión y endpoint. Producción y QA nunca se cruzan.

ERP

SIESA UnoEE o Siigo Nube, según la conexión que invoque.

Un acierto de caché responde aquí mismo: el ERP no se entera.

Cada ejecución se registra en paralelo, separando el tiempo del ERP del tiempo de la pasarela.

Las dos rutas de una consulta

Comparación de las dos rutas de una consulta: con acierto de caché la petición se resuelve sin llegar al ERP; con fallo, la pasarela ejecuta contra el ERP y guarda la entrada para la siguiente.
Acierto

La entrada está vigente para ese usuario, esa conexión y ese endpoint.

Autentica y resuelve el alcance
Encuentra la entrada vigente
No recibe la petición
Se responde desde la caché

El ERP no se entera: su carga no crece aunque la consulta se repita.

Fallo

No hay entrada, o el TTL de esa regla ya venció.

Autentica y resuelve el alcance
No hay entrada vigente
Ejecuta la consulta
Se responde y se guarda la entrada

La siguiente petición igual, dentro del TTL, ya es un acierto.

  • Solo se guardan lecturas: cualquier método distinto de GET se rechaza antes de llegar a la caché.
  • El alcance es usuario, conexión y endpoint: producción y QA de una misma empresa nunca comparten una entrada.
  • El TTL se configura por regla, y la entrada se puede invalidar a mano.

Seguridad

  • AES-256-GCMCifrado de secretos de conexión.
  • bcryptContraseñas nunca recuperables, ni por nosotros.
  • API keys con alcanceCada llave solo alcanza lo que heredó.
  • JWTSesión del portal, separada de las llaves máquina a máquina.
  • Instancia dedicadaBase y dominio de API propios por cliente.
  • El tercero no tiene credenciales del ERPNunca salen de la instancia.

Para qué lo conectan

  • Portal de clientesSaldos, facturas y estados de cuenta del ERP en un portal propio, sin duplicar datos ni sincronizar a mano.
  • Tableros de BIPower BI, Metabase o Looker leyendo del ERP por HTTP, sin un ETL que mantener.
  • Comercio electrónicoExistencias y precios del ERP expuestos a la tienda como endpoints de solo lectura.
  • Agentes y asistentesUn agente que responde con datos reales del ERP porque consume un endpoint, no una base de datos.
  • AutomatizacionesMake, Zapier o n8n disparando contra endpoints REST en vez de contra un WebService SOAP.
  • Integradores externosUna casa de software recibe su llave con alcance heredado y su colección, sin credenciales del ERP.

Lo que hay debajo

  • Go
  • PostgreSQL
  • MongoDB
  • Redis
1.114
casos de prueba en verde
0
pruebas en rojo
1
ruta de ejecución para todo el catálogo
37
benchmarks de rendimiento
Gopher de Renée French, vector de Takuya Ueda · CC BY 3.0

No publicamos cifras de disponibilidad ni de latencia. No hay una página de estado que respalde un número de disponibilidad, y esos benchmarks no están medidos en un entorno comparable al suyo.

A-07 Puesta en marcha

Días, no semanas.

Es el tiempo de una integración que se apoya en el catálogo existente. Una integración con consultas nuevas o reglas de negocio propias toma más, y se estima caso por caso — no hay una cifra única que sirva para las dos cosas.

  1. 01

    Se registra la conexión

    Se registra la conexión con las credenciales que su ERP ya emitió, sin crear nada nuevo del lado del proveedor. Se prueba contra el sistema real antes de guardar: si no responde, no queda registrada.

  2. 02

    Nace el endpoint

    Contra SIESA se pega el script T-SQL existente y se marcan los parámetros. Contra Siigo se declara la operación REST. En ambos casos el sistema infiere los parámetros y propone un ejemplo.

  3. 03

    El guard revisa y alguien firma

    El análisis bloquea toda escritura sobre tabla real del ERP. El endpoint pasa por revisión y aprobación antes de responder.

  4. 04

    Se entrega

    Colección de Postman y fragmentos en cURL, fetch, Go, Dart y PHP. Una sola ruta de ejecución para todo el catálogo.

A-08 Planes

El cupo está definido. El precio se conversa.

Cada plan trae un cupo de peticiones por mes calendario, y el plan pertenece a la instancia desplegada. El valor depende del alcance de la integración, así que no publicamos una tabla de precios que después haya que matizar en la llamada.

Planes disponibles con su cupo de peticiones por mes calendario.
PlanCupo mensualUnidadPrecio
Basic120.000peticiones al mesA convenir
Profesional500.000peticiones al mesA convenir
Ultra1.000.000peticiones al mesA convenir
IlimitadoSin cupopara partnersA convenir

Todos los cupos son peticiones por mes calendario sobre la instancia, no por usuario, y el precio de cada plan se acuerda según el alcance. Si su volumen no encaja en ninguno de los cuatro, se dimensiona a la medida.

Pedir una cotización para su caso

A-09 Preguntas

Lo que un equipo técnico pregunta antes de firmar.

¿Qué sistemas están conectados hoy?

Dos, en producción: ERP SIESA UnoEE y Siigo Nube. No hay más conectores hoy, y no se insinúan. Cualquier otro sistema —Odoo, SAP Business One o el que sea— se integra bajo demanda, como trabajo acotado sobre la misma plataforma: misma ruta de ejecución, mismo gobierno y mismo contrato de respuesta.

¿Tengo que reescribir mis consultas?

No. El motor acepta el script T-SQL completo que su equipo ya usa, con SET NOCOUNT ON, variables y tablas temporales. Solo se marcan los huecos de los parámetros.

¿Puede alguien escribir en mi ERP desde un endpoint?

No. Los endpoints de consulta son de solo lectura y no escriben sobre ninguna tabla del ERP, sin excepción de verbo, de parámetro ni de perfil. Sí admiten el trabajo intermedio que un informe necesita, con tablas temporales y varias sentencias. DELETE, DROP, TRUNCATE y ALTER están bloqueados sin excepción. El registro en el ERP es otra cosa: se publica deliberadamente como un endpoint aparte y pasa por revisión y aprobación.

¿Sirve también para registrar, no solo para consultar?

Sí. El catálogo incluye operaciones de escritura contra Siigo —crear facturas, notas crédito, comprobantes— y el registro contra SIESA se publica como endpoint aparte, con revisión y aprobación. Las escrituras nunca se reintentan automáticamente, por diseño.

¿Cómo evitan que mi consumo tumbe el proveedor?

Usted fija el techo de consumo hacia el proveedor en cada conexión y la pasarela no lo excede: su equipo no programa esperas ni colas para respetarlo. Cuando el proveedor deja de responder, la pasarela deja de insistir en vez de castigarlo, y su aplicación lo ve declarado en la respuesta. Una escritura jamás se reintenta automáticamente.

¿Qué pasa cuando un endpoint queda obsoleto?

Se retira con encabezados RFC 8594: el consumidor recibe la fecha de retiro y un enlace a su sucesor en la propia respuesta, antes de que el endpoint deje de responder.

¿Cuánto tarda la puesta en marcha?

Días, no semanas, para una integración que se apoye en el catálogo existente. Una integración con consultas nuevas o reglas de negocio propias toma más y se estima caso por caso.

¿Publican cifras de disponibilidad o de latencia?

No, y es deliberado. No hay una página de estado que respalde un número de disponibilidad, y los 37 benchmarks del repositorio no están medidos en un entorno comparable al suyo. Preferimos no imprimir una cifra que no podamos sostener en una auditoría.

Traiga una consulta. Salimos con un endpoint.

La conversación útil empieza con un reporte concreto que su equipo ya corre. En esa misma llamada se ve si el catálogo lo cubre o si hay que escribirlo.

  • El reporte o la consulta que necesita exponer, tal como existe hoy.
  • Qué aplicación va a consumirlo: portal, tablero, tienda, agente o un tercero.
  • Si ya tiene credenciales del WebService UnoEE o la llave API de Siigo.
Aprobado porAgendar demo
Emisión18/09/2026