API REST instantánea para bases de datos SQL populares — sin compartir credenciales.
Convierta cualquier consulta SQL guardada en un punto final REST listo para socios, con claves API por destinatario, cuotas mensuales de bytes y un registro de auditoría completo. Estático o en tiempo real, JSON, NDJSON o CSV, compresión LZ4 en la transmisión: todo ello sin necesidad de infraestructura de alojamiento y sin exponer SQL al destinatario.
Pregunte a Nova, obtenga SQL + gráficos
Conoce a Nova
Una clave por socio. No se comparten las credenciales.
Crea una API
+más
Sincronización programada con más de 6 plataformas
Explore
+más
Consulta de API con SQL, sin código
Explore
+más
Claude, Cursor, ChatGPT y Grok se comunican con tus datos.
Conectar IAQuery Streams es una plataforma segura de integración de datos en tiempo real que convierte cualquier consulta SQL guardada en un punto final de API REST listo para su uso por parte de socios, con claves por destinatario, cuotas mensuales de bytes y un registro de auditoría completo. La plataforma API le permite compartir datos de bases de datos en tiempo real con clientes, proveedores y equipos internos sin necesidad de proporcionar credenciales de base de datos, código SQL ni la topología de su red. Más información en QueryStreams.com y regístrese gratis Crea tu primera API compartida en cinco minutos.
Comparta datos de bases de datos en tiempo real como una API REST, sin compartir credenciales.
La mayoría de los equipos envían exportaciones CSV, distribuyen cuentas de base de datos de solo lectura o configuran un servicio Express personalizado cuando un socio necesita datos en tiempo real. Cada enfoque tiene el mismo problema: el socio termina teniendo algo que no debería tener: una bandeja de entrada llena de CSV obsoletos, una credencial SQL que sobrevive mucho después de que finaliza el acuerdo o acceso de administrador a un servicio que nadie mantiene activamente. La plataforma API de Query Streams le permite compartir la Capacidad para ejecutar una consulta guardada.No se trata de las credenciales subyacentes. Cada destinatario recibe su propia clave API, cada llamada está limitada en frecuencia y se audita, y el acceso se puede revocar desde el Portal con un solo clic sin necesidad de cambiar ninguna contraseña de la base de datos.
Claves API por destinatario
Cada destinatario recibe el suyo propio. qsapi_* Clave. Revoca una sin tocar las demás. Rota sin volver a desplegar nada.
Las credenciales nunca salen de tu red
El agente de red realiza la llamada desde su entorno. El destinatario ve un punto final REST, nunca el nombre de host de su base de datos, su contraseña ni su clave SQL.
Diseño de solo lectura
El mecanismo de control de solo lectura del agente rechaza cualquier instrucción que no sea SELECT antes de que llegue a la base de datos. No existe la posibilidad de que se produzca una eliminación accidental.
Modos de respuesta estáticos y en tiempo real
Seleccione un único cuerpo almacenado en búfer (8 MB / 100.000 filas por defecto) o una transferencia por fragmentos que envíe las filas a medida que el agente las produce (1 GB / 10 millones de filas por defecto).
Compresión de cables LZ4-frame + gzip
Modo de carga útil de trama LZ4 opcional para consumidores de SDK (descompresión en una línea), además de estándar Codificación aceptada: gzip en las rutas sin comprimir.
Arenero estilo cartero construido en
Pruebe cada punto final dentro del Portal antes de compartirlo. Ajuste los parámetros de consulta, inspeccione el JSON, copie el rizo — sin espacio de trabajo de Postman independiente.
CORS + listas de direcciones IP permitidas
Vincule la clave de un destinatario a direcciones IP o CIDR específicas, restrinja los orígenes del navegador por punto final y aplique los límites de velocidad estándar de dos niveles.
Especificación OpenAPI 3.1 por punto final
Cada punto final expone un formato legible por máquina. openapi.json. Introdúzcalo en Postman, Swagger UI o un generador de SDK como openapi-typescript.
Bases de datos SQL populares compatibles
La plataforma API funciona con las bases de datos SQL que la mayoría de los equipos ya utilizan. Una vez conectado el agente de red, todas las consultas guardadas en una base de datos compatible se pueden convertir en un punto final REST compartido, sin necesidad de configuración ni SDK específicos para cada base de datos.
Las bases de datos alojadas en la nube funcionan de la misma manera.
El agente se conecta igualmente bien a bases de datos locales y a servicios gestionados como AWS RDS, Azure SQL Database, Google Cloud SQL y Snowflake. Para obtener la mejor latencia, implemente el agente en la misma región que la base de datos; una cuenta de Query Streams puede ejecutar varios agentes en diferentes regiones y nubes.
Cómo funciona en tres pasos
Una vez configurados el agente de red y un conector de base de datos compatible, la promoción de una consulta guardada a una API compartida tarda aproximadamente cinco minutos:
Guardar una consulta SQL
Crea la consulta en el Generador de consultas del portal para cualquier base de datos conectada. Agrega filtros, parámetros y un nombre. Todo lo que puedas seleccionar es integrable mediante API.
Conviértelo en una API.
Abra la pestaña Instalar. Elija un tipo de punto final (permanente, con caducidad o presupuesto de llamadas N-shot), un formato interno (JSON, NDJSON o CSV), un modo de respuesta (estático o en tiempo real) y si se permite la compresión de datos LZ4. Guarde.
Invitar a los destinatarios por correo electrónico
Introduce el correo electrónico de un socio; recibirá una invitación para reclamar el enlace mágico. Los destinatarios que no tengan una cuenta de Query Streams obtendrán una organización gratuita creada automáticamente al reclamar el enlace; su clave se emitirá en el momento en que la acepten.
¿Ya utilizas Query Streams para Excel o Google Sheets?
Entonces su Agente de red ya está en su lugar y su base de datos ya está conectada. Promover una consulta guardada existente a un punto final REST lleva aproximadamente un minuto; omite los pasos 1 y la mayor parte del paso 2. La misma consulta guardada puede alimentar una actualización de Excel, una barra lateral de Hojas de cálculo, y un punto final REST orientado a los socios al mismo tiempo.
Seleccione un modo de respuesta: estático o en tiempo real.
Cada punto final elige uno de dos modos de respuesta al crearse. El modo controla cómo se envían los bytes desde nuestros servidores; el formato de transmisión (JSON, NDJSON, CSV o trama LZ4) lo elige el destinatario de forma independiente para cada llamada.
El valor predeterminado. Recopilamos cada fila en una única respuesta almacenada en búfer, configurada. Longitud del contenidoy emiten un cuerpo. Los errores son códigos de estado HTTP normales (200, 400, 413 API_OUTPUT_TOO_LARGE, 503).
- Límites predeterminados: 8 MB / 100.000 filas por llamada
- Plataforma máxima: 50 MB / 1.000.000 de filas por llamada
- Ideal para: paneles de control, búsquedas bajo demanda, consultas de menos de 10 000 filas, curl, herramientas de IA que requieren un único blob JSON.
Regresamos 200 OK + Codificación de transferencia: fragmentada En cuanto llega la primera fila, se envían las filas siguientes a través del cable a medida que el agente las genera. La memoria en nuestro extremo permanece limitada independientemente del tamaño del resultado.
- Límites predeterminados: 1 GB / 10.000.000 filas por llamada
- Plataforma máxima: 50 GB / 100.000.000 filas por llamada
- Ideal para: Flujos de n8n/Zapier, pipelines de análisis, exportaciones masivas, cualquier cosa que se beneficie del tiempo hasta el primer byte.
Los errores que se producen durante la transmisión en un punto final de transmisión no se pueden expresar como un código de estado HTTP (el estado ya se envió con el primer fragmento). Los mostramos como un último registro centinela: {"_error":"...","rows_returned":N} para NDJSON o # error: ..., filas_devueltas: N Para la transmisión de datos CSV, las bibliotecas consumidoras deben verificar el último registro antes de considerar que la transmisión está completa.
Seleccione un formato de transmisión: JSON, NDJSON, CSV o trama LZ4.
Dentro del modo de respuesta elegido, los destinatarios seleccionan el formato de transmisión por llamada utilizando encabezados HTTP estándar (Aceptar para el formato interior y Codificación de aceptación (para compresión). Un único punto final puede admitir los cuatro formatos; el propietario también puede restringir el punto final a un solo formato desde la pestaña Instalar.
Un único array JSON. Valor predeterminado para el modo estático. El formato universal para clientes web, herramientas de IA y usuarios de curl.
# Python datos = requests.get(url, headers=h).json()
JSON delimitado por saltos de línea, una fila por línea. Solo para transmisión en tiempo real. Análisis continuo para pipelines y ETL.
# Python para línea en resp.iter_lines(): fila = json.loads(línea)
Formato CSV RFC 4180. Funciona en modo estático (un solo cuerpo) o en modo continuo (encabezado en el primer fragmento). Ábralo con Excel, pandas, R o cualquier programa que lea archivos CSV.
# pandas
df = pd.read_csv(url, storage_options=h)
El formato de marco LZ4 compatible con los estándares (mágico) 04 22 4D 18). Un fotograma para estático; fotogramas concatenados mediante transferencia por bloques para transmisión en tiempo real. Facturación por bytes comprimidos.
# Python
datos = lz4.frame.decompress(resp.content)
Para los consumidores que desean la máxima interoperabilidad, JSON simple (o CSV) es suficiente; todo lo demás es opcional. La compresión de cables (gzip) se aplica automáticamente sobre las rutas sin comprimir a través del estándar. Codificación de aceptación encabezado; nunca realizamos doble compresión, por lo que LZ4-frame reemplaza a gzip en lugar de superponerse a él.
Las cuatro combinaciones de cables de un vistazo
El modo de respuesta y la compresión de la carga útil se componen en cuatro rutas hoja. El propietario del punto final elige los valores predeterminados en la pestaña Instalar; el destinatario puede anularlos por llamada (dentro de lo que el propietario permite). Compresión de cable (gzip) negociada a través de Codificación de aceptación Las capas se superponen automáticamente a las dos filas sin comprimir.
Un único búfer aplicación/json (o texto/csv) cuerpo con Longitud del contenido. Ruta predeterminada. Compresión de datos (gzip) negociada automáticamente.
Un solo aplicación/x-lz4-frame Cuerpo que contiene un marco LZ4 estándar (multibloque). Descomprímalo en una línea de código de consumidor.
aplicación/x-ndjson (o transmisión en directo) texto/csv) encima Codificación de transferencia: fragmentadaUna fila por fragmento. La compresión de datos (gzip) se negocia automáticamente.
aplicación/x-lz4-frame como una secuencia de tramas LZ4 estándar concatenadas mediante transferencia por bloques. Sin protocolo de trama inventado por QS.
| Modo + compresión | Tipo MIME de cable | Forma del cuerpo | límites predeterminados | Proyectos de ley sobre | Caso de uso |
|---|---|---|---|---|---|
| estático + ninguno | aplicación/json o texto/csv |
Un cuerpo amortiguado, Longitud del contenido |
8 MB / 100.000 filas | bytes sin comprimir | Paneles de control, curl, predeterminado |
| estático + lz4 | aplicación/x-lz4-frame |
Bastidor LZ4 único (multibloque) | 8 MB comprimidos | bytes comprimidos | Consumidores de SDK, respuesta única optimizada en costos |
| transmisión + ninguna | aplicación/x-ndjson o texto/csv |
Transferencia fragmentada, NDJSON por fila | 1 GB / 10 millones de filas | bytes sin comprimir | n8n, Zapier, pipelines de análisis |
| transmisión + lz4 | aplicación/x-lz4-frame |
Transferencia fragmentada, tramas LZ4 concatenadas | 1 GB comprimido (~5 GB sin comprimir) | bytes comprimidos | Exportación masiva, SDK para usuarios avanzados, la combinación más económica y rápida. |
Filtros de paso en el momento de la llamada
Cualquier parámetro de consulta guardada que el propietario exponga puede ser configurado por el destinatario en cada llamada. CONSEGUIR Las solicitudes utilizan la cadena de consulta; CORREO Las solicitudes utilizan un cuerpo JSON. El agente vincula los parámetros como valores de sentencias preparadas adecuados, nunca como concatenación de cadenas, por lo que el destinatario no puede salirse de un parámetro para inyectar SQL.
El propietario del punto final controla qué parámetros se exponen (en la subpestaña Parámetros de la pestaña Instalar), cuáles están bloqueados a un valor fijo y cuál es el conjunto de valores permitidos. Los destinatarios solo pueden establecer parámetros que el propietario haya expuesto; todo lo demás es fijo. Los parámetros de múltiples valores utilizan claves repetidas (?estado=pagado&estado=enviado) en GET y un array JSON estándar en POST.
Postura de seguridad: CORS, listas de direcciones IP permitidas y límites de velocidad.
Además de las claves por destinatario y la restricción de solo lectura, cada punto final ofrece cuatro medidas de seguridad adicionales que puedes reforzar antes de compartirlo.
Lista de direcciones IP permitidas por clave
Asocia la clave de un destinatario a una única IP, un rango CIDR o una lista. Admite IPv4 e IPv6. Una llamada desde fuera de la lista de permitidos devuelve 403 IP_NO_PERMITIDA antes de que se modifique el SQL.
Lista de permisos CORS por endpoint
Indíquenos qué orígenes de navegador tienen permitido llamar al endpoint desde JavaScript. ["https://app.acme.com"] para un único socio, o bien desactive CORS por completo (opción predeterminada) para puntos finales que solo se comuniquen entre servidores.
Límites de tarifas de dos niveles
Un depósito de tokens en la clave del destinatario (60 solicitudes/min por defecto) más un segundo depósito en el propio punto final (120/min por defecto). Un destinatario que haga mucho ruido no puede agotar el presupuesto destinado a los que se comportan correctamente.
Cuotas mensuales de bytes
Límite opcional por punto final en los bytes facturados por mes calendario. Cuando se alcanza el límite, las llamadas devuelven 429 FINAL_CUOTA_AGOTADO hasta que se reinicie el período. Un límite seguro de radio de explosión para nuevos socios.
Cada punto final se envía con una especificación OpenAPI 3.1.
Cada punto final expone una especificación legible por máquina en OBTENER /v1/endpoints/{id}/openapi.jsonDescribe la URL, el método, cada parámetro (con su tipo, valores permitidos y predeterminado), cada estructura de respuesta por formato (JSON, NDJSON, CSV, LZ4-frame) y cada código de error. Péguelo en Postman o Insomnia para generar una colección de solicitudes, utilícelo en Swagger UI para obtener documentación interactiva o ejecútelo a través de un generador de SDK para obtener un cliente tipado en el lenguaje de programación que prefiera.
Consúmelo desde Power BI, Tableau y cualquier herramienta JSON.
Porque cada punto final devuelve un estándar JSON —junto con CSV y transmisión de NDJSON— cualquier herramienta que pueda leer una fuente REST consume sus datos directamente, sin necesidad de instalar nada en el lado del destinatario. Power Query es el puente más fácil hacia la pila de BI de Microsoft: en Power BI elegir Obtener datos → Desde la web, pegue la URL del punto final, agregue el Autorización encabezado, y Power Query analiza el JSON en una tabla actualizable que alimenta su modelo de datos. (Para datos en vivo dentro de una hoja de cálculo, la función nativa Complementos de Query Streams para Excel y Google Sheets son la opción más sencilla: Power Query está ahí cuando se necesitan los datos en el propio modelo de BI.
Power Query
Obtener datos → Desde la web, pegue la URL y el token de portador, expanda el JSON a una tabla actualizable.
Power BI
El mismo motor de Power Query: cargue el punto final en su modelo y programe la actualización.
Tableau
Apunte un conector de datos web o una fuente JSON al punto final para los paneles de control en tiempo real.
Cartero
Importa la especificación OpenAPI 3.1 y, a continuación, envía, inspecciona y comparte solicitudes con un solo clic.
También alimenta n8n, Qlik, rizo, Python (solicitudes o pandas.read_json), Insomnia, Hoppscotch, o cualquier script o flujo de trabajo que pueda enviar una solicitud HTTP y leer JSON.
Prueba los puntos finales en tu navegador, al estilo Postman, sin salir del Portal.
Antes de entregar una clave a un socio, ejecute usted mismo el endpoint. La pestaña Instalar incluye un generador de solicitudes integrado que reproduce lo que verá el destinatario: seleccione el método HTTP, configure los parámetros de consulta, elija un ejemplo, envíe la solicitud e inspeccione la respuesta. El entorno aislado utiliza una clave efímera de corta duración, por lo que la llamada sigue exactamente el mismo camino que la solicitud del destinatario: misma autenticación, mismo envío de agente, misma negociación de compresión, mismo registro de bytes.
Facturación con reconocimiento de compresión
Los recuentos de bytes en su libro mayor de actividad son medido en la salida de nuestro servidor API y seguir una regla simple y predecible: si el destinatario optó por participar Compresión de carga útil de fotogramas LZ4 (Codificación aceptada: lz4), la llamada factura en los bytes comprimidos que realmente viajaron por el cable; si no, la llamada factura en los bytes sin comprimir. Compresión de cable HTTP estándar (gzip) es una optimización de transporte pura y no afecta a la facturación; esa compresión se produce después de que medimos los bytes que se le pide al consumidor que “vea”.
Nota sobre bytes en la red
Si una llamada opta por la compresión de tramas LZ4, la misma carga útil JSON normalmente se factura a aproximadamente el 25-40% de su tamaño sin comprimir para filas transaccionales, y el 10-20% para cargas de trabajo analíticas con columnas repetidas, porque esa es la cantidad de datos que la red de su socio realmente movió. El entorno aislado en el navegador muestra ambos números (Cable de bytes X-QS y X-QS-Bytes-Raw) para que pueda ver los ahorros antes de compartir un punto final. Elegimos facturar por bytes de cable (cuando se opta por LZ4) porque ese es el número que coincide tanto con sus costos de salida de datos como con el consumo de ancho de banda del destinatario. Compresión de cable HTTP estándar (gzip) es una optimización pura del transporte y no afecta a la facturación. Las llamadas que no solicitan LZ4 continúan facturándose en bytes sin comprimir., de forma similar a como se facturan actualmente Excel, Hojas de cálculo y el servidor MCP.
La descompresión en el lado del consumidor se realiza en una línea por idioma. A continuación se muestra el código de integración estándar para cada entorno para el que distribuimos ejemplos:
Diseñado para compartir datos entre socios, no para API a escala de internet.
La plataforma API de Query Streams está diseñada para casos de uso donde se conocen los destinatarios: clientes, proveedores, equipos internos, reguladores, auditores y miembros de la junta directiva. Las cuotas de los puntos finales, los límites mensuales de bytes y los límites de velocidad por destinatario asumen entre decenas y miles de llamadas diarias por destinatario. Si su caso de uso es una API de marketing pública que necesita atender millones de solicitudes anónimas por segundo, probablemente le convenga una puerta de enlace API como Kong, Apigee o AWS API Gateway que se ubique delante de un servicio desarrollado internamente. La plataforma API complementa este modelo; no lo reemplaza.
Preguntas frecuentes
¿Necesito abrir los puertos de entrada del firewall para exponer mi base de datos como una API? +
¿Puede el destinatario ver mis credenciales SQL o de mi base de datos? +
¿Cómo puedo revocar el acceso a la API de un socio? +
401 CLAVE REVOCADALos demás destinatarios del mismo punto final seguirán trabajando con sus propias claves y no será necesario cambiar la contraseña de la base de datos.¿Cuál es la diferencia entre los modos de respuesta estática y de transmisión continua? +
Longitud del contenidoy emite un cuerpo HTTP. Los límites predeterminados son 8 MB / 100 000 filas; el máximo de la plataforma es 50 MB / 1 millón de filas. Ideal para paneles de control, consultas de menos de 10 000 filas y usuarios de curl. Transmisión El modo emite Codificación de transferencia: fragmentada y envía las filas a través de la red a medida que el Agente las genera. Los límites predeterminados son 1 GB / 10 millones de filas; el máximo de la plataforma es de 50 GB / 100 millones de filas. Ideal para flujos de n8n / Zapier, canalizaciones de análisis y exportaciones masivas. Usted selecciona el modo por punto final; el destinatario selecciona el formato de transmisión (JSON, NDJSON, CSV o trama LZ4) por llamada.¿Cómo puedo descomprimir las respuestas de tramas LZ4 en mi código? +
04 22 4D 18), por lo que todas las bibliotecas LZ4 principales lo manejan de forma nativa. En Python: lz4.frame.decompress(resp.content). En Node.js con lz4js: LZ4.descomprimirFrame(buffer). En Go with github.com/pierrec/lz4/v4: lz4.NewReader(cuerpo). En la interfaz de línea de comandos: curl ... | lz4 -d -Para los puntos finales de transmisión, el cuerpo de la respuesta es una secuencia de tramas LZ4 concatenadas. Codificación de transferencia: fragmentada — El mismo decodificador de tramas maneja de forma idéntica las entradas de una sola trama y las tramas concatenadas cuando se llama en un bucle de transmisión.¿Puedo restringir un punto final a direcciones IP o orígenes de navegador específicos? +
403 IP_NO_PERMITIDA antes de que se ejecute cualquier SQL. Por separado, cada punto final tiene una opción Lista de permitidos de origen CORS — configurarlo en ["https://app.acme.com"] Si el punto final está destinado a ser llamado desde el frontend de un socio específico, o bien, puede dejarlo completamente desactivado (opción predeterminada) para puntos finales que solo se comunican entre servidores. Ambos controles se editan desde la pestaña Instalar y se aplican de inmediato.¿Cómo se factura el uso de la plataforma API? +
Codificación aceptada: lz4), factura en función de los bytes de la red comprimidos; si no, factura en función de los bytes sin comprimir. La misma carga útil JSON a través de LZ4 normalmente factura entre el 25 % y el 40 % de su tamaño sin comprimir para filas transaccionales y entre el 10 % y el 20 % para cargas de trabajo analíticas, porque esa es la cantidad de datos que la red de su socio realmente movió. El entorno aislado del navegador muestra ambos números uno al lado del otro. Compresión de red HTTP estándar (gzip) es una optimización pura del transporte y no afecta a la facturación.¿Qué ocurre si una consulta intenta escribir o eliminar datos? +
SOLO LECTURA_VIOLACIÓN Antes de que llegue a su base de datos, el validador de solo lectura del Agente se ejecuta en su red y solo permite sentencias SELECT. Por qué todos los puntos finales son de solo lectura por diseño →¿Qué bases de datos SQL admite la plataforma API? +
¿Puedo ver qué solicitó exactamente cada destinatario? +
¿Cómo se compara esto con la creación de una API por mi cuenta con Express, FastAPI o PostgREST? +
¿La plataforma API necesita una suscripción independiente además de Query Streams? +
Comenzar
Crea tu primera API compartida en cinco minutos.
Regístrate gratis, instala el Agente de red junto a tu base de datos, guarda una consulta SQL y envía por correo electrónico una invitación con enlace mágico a un destinatario. Las claves por destinatario, el registro de auditoría y la facturación con compresión están disponibles desde el primer minuto.
Guías relacionadas: Comparta datos de bases de datos en tiempo real sin compartir credenciales. | Comparta los resultados de la consulta de forma segura. | Guías de configuración de conectores | Todas las guías del servidor MCP
Categoría: Plataforma API
Etiquetas: plataforma-api, api-rest, compartir-datos-en-vivo, api-de-socios, claves-por-destinatario, sql-a-api, api-instantánea, api-de-streaming, ndjson, compresión-lz4, api-abierta, postgres, mysql, sql-server, snowflake
Meta Descripción: API REST instantánea para bases de datos SQL populares: estática o en tiempo real, JSON/NDJSON/CSV/LZ4-frame, claves por destinatario, OpenAPI 3.1, sin credenciales compartidas.
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish