DEV Community: Roobia

GPT-Image-2.6 Flare vs Sunburst: ¿qué modelo deberías usar?

Roobia — Thu, 05 Nov 2026 10:45:28 +0000

GPT-Image-2.6 Flare vs Sunburst: ¿qué modelo deberías usar?

Usa GPT-Image-2.6 Flare para borradores, trabajos de gran volumen, pósteres e imágenes de producto. Usa Sunburst para los recursos finales y para ediciones repetidas con calidad medium o high. En la decisión entre GPT-Image-2.6 Flare y Sunburst, ambos modelos cuestan lo mismo por token, así que estás cambiando segundos por detalle, no dólares.

Prueba Apidog hoy

OpenAI lanzó ambos modelos el 4 de noviembre de 2026. Este artículo los compara en velocidad, calidad, consistencia de edición y costo, y luego te da una recomendación para cada caso de uso. No hemos ejecutado los dos modelos frente a frente con una clave activa, así que cada cifra a continuación indica su fuente, y la última sección muestra cómo medirlos con tus propios prompts.

Para conocer el lanzamiento completo, lee nuestra explicación de ChatGPT Images 2.6. Para el par anterior, consulta nuestra comparación de Flare vs Sunburst para la 2.5.

GPT-Image-2.6 Flare vs Sunburst de un vistazo

Elemento	Flare	Sunburst
ID del modelo en la API	`gpt-image-2.6-flare`	`gpt-image-2.6-sunburst`
El eslogan de OpenAI	Iteración rápida	Trabajo visual detallado
Velocidad publicada	Tan solo seis segundos con `low`	Sin cifra
Fortaleza según OpenAI	Composición para pósteres e imágenes de producto	Calidad y consistencia de edición con `medium` o `high`
Text-to-Image Arena (Medium)	#4, 1384 puntos	#2, 1409 puntos
Image Edit Arena (Medium)	#5, 1462 puntos	#3, 1476 puntos
Tarifa de salida de imagen	$30 por 1M de tokens	$30 por 1M de tokens
`complexity`, markup, SVG, GIF	Sí	Sí

Las filas de características coinciden. La guía de generación de imágenes de OpenAI indica que ambos modelos admiten control de complejidad, ediciones guiadas por markup, salida SVG y salida GIF animado. No renuncias a ninguna capacidad con ninguno de los dos.

Velocidad: gana Flare, pero la diferencia no está publicada

Flare es el modelo más rápido. La publicación de lanzamiento de OpenAI dice que puede generar una imagen en tan solo seis segundos con calidad low, y que Images 2.6 se ejecuta un 50 % más rápido que antes. No da ningún tiempo para Sunburst, y las páginas de modelo de Flare y Sunburst indican la velocidad como «Not specified» (no especificada).

Lee esa cifra de seis segundos con cuidado:

Es un caso óptimo («tan solo»), no un promedio.
Solo aplica a la calidad low.
OpenAI no dice qué ajuste de complexity la produjo, y la API usa high por defecto.

Aún no encontramos ningún tiempo independiente para la 2.6. La evidencia más cercana proviene del par 2.5, así que tómala como una guía aproximada:

Prueba (modelos 2.5)	Flare	Sunburst	Sunburst tarda
Pixmax, render de 2048x1152 emparejado	19,7 s	27,7 s	1,4 veces más
PoYo, mediana de un benchmark de 12 solicitudes	30,89 s	35,06 s	1,1 veces más

Ambas pruebas sitúan a Flare por delante, pero no coinciden en cuánto. La diferencia depende de tu prompt y tus ajustes, así que un solo benchmark no lo resolverá para tu carga de trabajo. La guía de OpenAI también advierte que los prompts complejos pueden tardar hasta dos minutos en los modelos GPT Image, así que configura un timeout de cliente generoso con cualquiera de los dos.

Calidad: Sunburst lidera, por poco

Sunburst obtiene mejores puntuaciones en las dos clasificaciones de Arena que Arena publicó el 5 de noviembre, y se llevó el primer puesto en la categoría de Cartoon, Anime y Fantasy. Flare sigue estando entre los cinco primeros en ambas tablas.

Ten en cuenta tres límites al leer esas puntuaciones:

Son votos de preferencia del público, no un benchmark de OpenAI.
Ambas entradas se ejecutaron en Medium, así que no dicen nada sobre low o max.
Las puntuaciones de Arena cambian a medida que llegan votos. Las leímos de la publicación de Arena, no del tablero en vivo.

Una ventaja de 25 puntos en Text-to-Image significa que los votantes tendieron a preferir la salida de Sunburst. No significa que las imágenes de Flare sean malas. En un póster o una foto de producto, la promesa de composición que OpenAI hace para Flare puede importarte más que una puntuación de preferencia general, así que prueba esa categoría tú mismo.

Consistencia de edición: la principal promesa de Sunburst

La consistencia de edición es la razón por la que pagarías la espera extra de Sunburst. OpenAI dice que aporta «una consistencia de imagen aún mayor entre ediciones» con calidad medium o high, lo que ayuda cuando un personaje, producto o logotipo tiene que sobrevivir a varias rondas de cambios.

Aquí hay menos pruebas públicas de las que cabría esperar:

OpenAI no publica ninguna métrica de consistencia.
La tarjeta del sistema dice que ambos modelos actualizados mejoran la consistencia de edición y la preservación del detalle, así que Flare también gana.
La diferencia de Arena en Image Edit es de 14 puntos, menor que los 25 puntos de Text-to-Image. Esa tabla puntúa qué edición prefirieron los votantes, no si un sujeto se mantuvo estable a lo largo de cinco rondas.

Así que Sunburst es la opción predeterminada más segura para ediciones de varias rondas, pero solo tu propia cadena de ediciones puede confirmar que vale la pena el tiempo. Para un cambio único y concreto, como cambiar un fondo o corregir un cartel, prueba Flare primero.

Elijas el modelo que elijas, configura complexity tú mismo. Si lo omites, ambos modelos usan high, mientras que OpenAI recomienda low para la mayoría de las ediciones. Su guía advierte que una mayor complejidad puede añadir latencia e introducir cambios no deseados, justo lo contrario de lo que necesita un flujo de trabajo de edición.

Costo: el mismo precio, así que la calidad es la verdadera palanca

Flare y Sunburst cuestan lo mismo. La página de precios lista ambos a $8 por 1M de tokens de entrada de imagen, $2 en caché y $30 de salida. La calculadora de OpenAI también los trata como una sola entrada, «GPT Image 2.6 (Sunburst and Flare)», así que la estimación de salida a continuación aplica a cualquiera de los dos modelos.

`quality` (1024x1024)	Tokens de salida	Costo por imagen	Costo por 1.000
`low`	823	$0,02469	$24,69
`medium`	1.449	$0,04347	$43,47
`high`	1.756	$0,05268	$52,68
`xhigh`	3.122	$0,09366	$93,66
`max`	7.024	$0,21072	$210,72

Estas cifras excluyen los tokens de entrada de texto e imagen, y una edición factura su imagen de referencia aparte. La calculadora señala que el uso de tokens puede variar, así que lee usage.output_tokens de las respuestas reales.

De esa tabla se derivan dos cosas:

Pasar de Flare a Sunburst cambia tu tiempo, no tu tarifa. Elegir high en lugar de low duplica aproximadamente tu costo de salida con cualquiera de los dos modelos.
De medium a high cuesta alrededor de un centavo más por imagen cuadrada. Como OpenAI vincula las mejoras de Sunburst a ambos niveles, compáralos antes de decidirte por medium.

Batch es el único punto a tener en cuenta en el costo. El 5 de noviembre, la pestaña Batch de la página de precios listaba la 2.5 a mitad de precio, pero no listaba ninguno de los modelos 2.6. Si ejecutas trabajos nocturnos con el par 2.5, revisa esa pestaña antes de cambiar.

¿Qué modelo deberías usar?

Usa Flare por defecto y luego pasa un trabajo a Sunburst cuando puedas ver la diferencia. Estos ajustes iniciales son nuestras sugerencias, no las de OpenAI, así que ajústalos después de tus primeras pruebas.

Caso de uso	Elección	`quality`	`complexity`
Borradores conceptuales e iteración rápida	Flare	`low`	`low`
Trabajos de imágenes de gran volumen	Flare	`low` o `medium`	`low`
Pósteres e imágenes de producto	Flare	`medium`	`medium`
Una edición concreta	Flare	`medium`	`low`
Ediciones repetidas sobre un mismo sujeto	Sunburst	`medium` o `high`	`low`
Imágenes finales destacadas y de campaña	Sunburst	`high`	`medium`
Arte de cartoon, anime y fantasía	Sunburst	`medium`	`medium`
Texto denso, muchos elementos con restricciones	Sunburst	`high`	`high`

Para GIF y SVG, OpenAI no publica ninguna diferencia de calidad o velocidad entre los modelos. Haz el borrador con Flare y luego vuelve a ejecutar tu mejor prompt con Sunburst y compara. Revisa primero dos detalles de los GIF: la guía de OpenAI permite de 2 a 64 fotogramas, mientras que su referencia de la API dice de 2 a 16, y la referencia indica que la salida GIF requiere acceso de vista previa para el modelo seleccionado.

Si fijas modelos en producción, ten en cuenta que ambas páginas de modelo muestran solo el alias el 5 de noviembre, sin una instantánea con fecha. Vuelve a comprobar tus prompts aprobados cuando OpenAI actualice un modelo.

Compara ambos modelos con Apidog CLI

Las puntuaciones públicas no pueden decirte cómo maneja cada modelo tus prompts. Tu agente de programación puede ejecutar el mismo conjunto de prompts con ambos modelos usando Apidog CLI y comparar los tiempos de respuesta. Configúralo una vez:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
apidog skill install

Guarda cinco prompts de tu carga de trabajo real en prompts.csv, con prompt como encabezado. Luego dale a Claude Code, Codex o Cursor un [REDACTED PROMPT]
In Apidog project , add POST https://api.openai.com/v1/images/generations
with a Bearer [REDACTED] from ah-96595b54133dd71b741cc9d4907506e2b3a06f289e0016f9de2d7fb43e327968. Create a test case that sends
model {{MODEL}}, prompt {{prompt}}, quality medium, complexity low and size
1024x1024. Assert status 200 and that data[0].b64_json exists.
Run it with prompts.csv once per model, gpt-image-2.6-flare and
gpt-image-2.6-sunburst, then compare the timings in the two JSON reports.


El agente lee cada esquema, valida su payload, crea el caso y luego lo ejecuta dos veces:

bash
apidog cli-schema get endpoint-create
apidog cli-schema validate endpoint-create --file endpoint.json
apidog endpoint create --project --file endpoint.json
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project --file case.json
apidog run --test-case --project -e -d prompts.csv \
--env-var "MODEL=gpt-image-2.6-flare" \
--env-var "OPENAI_API_KEY=$OPENAI_API_KEY" \
--timeout-request 180000 --on-error continue -r cli,json --out-file flare
apidog run --test-case --project -e -d prompts.csv \
--env-var "MODEL=gpt-image-2.6-sunburst" \
--env-var "OPENAI_API_KEY=$OPENAI_API_KEY" \
--timeout-request 180000 --on-error continue -r cli,json --out-file sunburst




Cada informe JSON almacena milisegundos bajo `result.timings`, en `responseAverage`, `responseMin`, `responseMax` y `responseSd`. Tu agente puede ponerlos uno al lado del otro y decirte la diferencia real con tus prompts. Diez imágenes en `medium` cuestan unos $0,43 en tokens de salida, más la entrada.

Construimos este flujo a partir de `apidog --help` y los esquemas de la CLI, y no lo hemos ejecutado contra OpenAI, así que revisa el primer informe antes de confiar en él. Apidog mide la velocidad y la corrección de la respuesta, no la calidad de la imagen, así que los píxeles los sigues juzgando tú. Para seguir midiendo el par después de cada actualización de modelo, mueve la ejecución a un [pipeline de CI](https://apidog.com/es/blog/apidog-cli-ci-cd-pipeline?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation), y consulta la [guía de configuración en Claude Code](https://apidog.com/es/blog/apidog-cli-in-claude-code?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) para más detalles sobre el agente.

## Preguntas frecuentes

**¿Es mejor Flare o Sunburst?** Ninguno gana en todo. Sunburst se clasifica más alto en las tablas de Text-to-Image e Image Edit de Arena, y OpenAI lo orienta al trabajo detallado. Flare está hecho para la velocidad. Empieza con Flare y pasa a Sunburst cuando puedas ver una mejora.

**¿Cuesta más Sunburst que Flare?** No. Ambos listan $8 de entrada de imagen, $2 en caché y $30 de salida por 1M de tokens, y comparten una sola entrada en la calculadora. Tu ajuste de calidad cambia la factura, no tu elección de modelo.

**¿Cuánto más rápido es Flare que Sunburst?** OpenAI no lo ha dicho. Solo da el caso óptimo de Flare, seis segundos con `low`. Dos pruebas independientes del par 2.5 mostraron que Sunburst tardaba entre 1,1 y 1,4 veces más, pero esos resultados pueden no trasladarse a la 2.6.

**¿Qué modelo es mejor para editar?** Usa Sunburst para ediciones repetidas sobre un mismo sujeto, con calidad `medium` o `high`. Prueba Flare para un cambio único y concreto. Configura `complexity` en `low` en ambos, ya que el valor por defecto es `high`.

**¿Pueden ambos modelos crear GIF y SVG?** Sí. La guía de OpenAI lista la salida GIF y SVG para ambos modelos en `POST /v1/images/generations`. El endpoint de ediciones no puede devolver ninguno de los dos formatos.

**¿Debería seguir usando GPT-Image-2.5?** Revisa primero Batch. La pestaña Batch listaba la 2.5 a mitad de precio el 5 de noviembre, pero no listaba la 2.6. La calculadora de OpenAI también muestra que la 2.6 usa más tokens con `low` y `medium`, así que los trabajos de gran volumen en `low` pueden costar menos con la 2.5.

¿Qué es ChatGPT Images 2.6? GIFs, exportación SVG y generación un 50% más rápida

Roobia — Thu, 05 Nov 2026 10:43:40 +0000

ChatGPT Images 2.6 es la actualización de generación de imágenes de OpenAI, publicada el 4 de noviembre de 2026 para ChatGPT, Codex y la API. Añade GIF animados, salida SVG para desarrolladores, marcado de imágenes y un ajuste de complexity, y OpenAI afirma que genera imágenes un 50% más rápido. La API lo distribuye como dos modelos: GPT-Image-2.6 Flare y GPT-Image-2.6 Sunburst.

Prueba Apidog hoy

Si leíste nuestro artículo explicativo sobre ChatGPT Images 2.5, esta publicación solo cubre lo que cambió. Hay un detalle que el anuncio de lanzamiento no menciona: las tarifas por token siguen igual, pero una imagen de calidad low ahora consume aproximadamente 4,2 veces los tokens de salida que consumía en 2.5.

ChatGPT Images 2.6 de un vistazo

Elemento	Detalle
Fecha de lanzamiento	4 de noviembre de 2026 (registro de cambios de la API)
Dónde funciona	ChatGPT, Codex y la API
Acceso en ChatGPT y Codex	Global, todos los niveles de suscripción, escritorio, móvil y web
IDs de modelo en la API	`gpt-image-2.6-flare`, `gpt-image-2.6-sunburst`
Aumento de velocidad	50% más rápido que antes; Flare en tan solo seis segundos con calidad `low`
Nuevas salidas	GIF animado (ChatGPT y API), SVG (API)
Nuevos controles	Marcado de imágenes, `complexity` (`low`, `medium`, `high`)
Tarifas de tokens de imagen	$8 entrada, $2 entrada en caché, $30 salida por 1M de tokens
Uso	4 mil millones de imágenes por semana en ChatGPT, Codex y la API

Qué hay de nuevo respecto a Images 2.5

Images 2.5 trajo Flare y Sunburst, los niveles de calidad xhigh y max, y funciones de ChatGPT como Sketch y Templates. La versión 2.6 mantiene la división en dos modelos y los cinco niveles de calidad, y añade lo siguiente:

Área	Images 2.5	Images 2.6
Salida animada	Ninguna	GIF, de 2 a 64 fotogramas en la API
Salida vectorial	Ninguna	SVG, solo en la API según la tarjeta del sistema
Control de planificación	Ninguno	`complexity`: `low`, `medium`, `high`
Ediciones guiadas por marcado	Primero en ChatGPT, compatibilidad con la API añadida el 4 de noviembre	ChatGPT y API
Tokens con `low`, 1024x1024	196	823
Precio de lote listado	Sí	No listado el 5 de noviembre
Imágenes semanales	"Más de 3 mil millones"	4 mil millones

La tarjeta del sistema de OpenAI también indica que ambos modelos mejoran la consistencia de las ediciones, la preservación del detalle y las respuestas a bocetos y anotaciones. El anuncio de lanzamiento no mide nada de eso con un benchmark público, y no especifica respecto a qué referencia se compara ese "50% más rápido", así que toma la cifra de velocidad como una afirmación de OpenAI hasta que cronometres tus propios prompts.

¿Quién puede usar ChatGPT Images 2.6?

OpenAI afirma que Images 2.6 está disponible globalmente en ChatGPT y Codex "en todos los niveles de suscripción", en escritorio, móvil y web. El acceso a la API se realiza a través de los dos modelos anteriores, y es posible que tengas que completar la verificación de organización de la API antes de poder llamarlos.

Quedan dos preguntas abiertas para los usuarios de ChatGPT:

Límites de GIF en el plan Free. Ni el anuncio de lanzamiento ni la página de precios de ChatGPT indican una cuota de GIF. La página de precios incluye la generación de imágenes como "Limitada" en Free.
Thinking. La misma página, consultada el 5 de noviembre, incluye "Generación de imágenes con Thinking" en Plus y Pro, pero no en Free ni en Go.

En Codex, la generación de imágenes se invoca con la habilidad $imagegen. Esa página aún no menciona la salida en GIF ni SVG.

Flare vs Sunburst: ¿qué hace cada modelo?

Flare es el modelo rápido para trabajo interactivo. OpenAI afirma que también mejora la calidad del diseño en carteles e imágenes de producto. Sunburst está pensado para composiciones detalladas, con mayor calidad y mejor consistencia entre ediciones con calidad medium o high.

Ambos modelos cuestan lo mismo por token y comparten una única entrada en la calculadora. Nuestra comparativa de Flare vs Sunburst para 2.5 explica esa división con más detalle, y la mayor parte sigue siendo válida.

Cómo funciona la generación de GIF

La API devuelve una animación terminada, no una hoja de sprites que tengas que ensamblar tú mismo. Los prompts de ejemplo del anuncio de lanzamiento piden una hoja de sprites de seis fotogramas en una cuadrícula de 3x2, pero la guía de generación de imágenes documenta una ruta directa:

Llama a POST /v1/images/generations con output_format: "gif".
Describe el sujeto, el movimiento y el bucle en tu prompt.
Establece frame_count (de 2 a 64, por defecto 9).
Establece frame_duration_ms (de 20 a 2000, redondeado a 10 ms, por defecto 200).
Decodifica b64_json desde base64 y guárdalo con extensión .gif.

curl --fail --silent --show-error https://api.openai.com/v1/images/generations \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2.6-flare",
    "prompt": "A small orange robot waves, blinks, and returns to its starting pose. Loop it.",
    "output_format": "gif",
    "frame_count": 9,
    "frame_duration_ms": 200,
    "size": "auto"
  }' | jq -er '.data[0].b64_json' | base64 --decode > robot.gif

Construimos esta solicitud a partir de la lista de campos de la guía y no la hemos ejecutado con una clave real, así que pruébala antes de implementarla.

Ten en cuenta estos límites:

/v1/images/edits no puede devolver GIF, por lo que no puedes animar una imagen subida a través de ese endpoint.
La salida GIF no admite streaming, imágenes parciales, output_compression personalizado ni prompt_rewriter.
El número de fotogramas, el tamaño de fotograma y n deben ajustarse a un presupuesto total de píxeles. Si una solicitud falla, reduce uno de ellos.

Exportación SVG: qué obtienes

Establece output_format: "svg" en POST /v1/images/generations para iconos, logotipos e ilustraciones que necesiten trazados, formas y colores editables. La API primero crea una imagen de referencia y luego genera el SVG a partir de ella; quality controla esa imagen de referencia.

La salida es contenido vectorial estático, sin scripts, recursos externos ni mapas de bits incrustados. Las restricciones son estrictas: n debe ser 1, no hay streaming y ni output_compression ni prompt_rewriter funcionan. El endpoint de ediciones no puede generar SVG, y un SVG no puede ser una entrada raster para ediciones.

La facturación también es distinta. Pagas la tarifa del modelo de imágenes por la imagen de referencia, más la tarifa de un modelo de autoría por los tokens que escriben el SVG. OpenAI no publica un precio fijo por SVG, así que mídelo con tus propios prompts.

El parámetro complexity y el marcado de imágenes

complexity determina cuánto planifica el modelo antes de renderizar. quality determina el nivel de detalle del renderizado. Son controles independientes, y ajustar la complejidad no conlleva ningún cargo adicional.

Ojo con el valor predeterminado. Si omites complexity, ambos modelos usan high, aunque OpenAI recomienda low para la mayoría de las ediciones, combinado con la calidad que necesites. La guía advierte que una mayor complejidad puede añadir latencia e introducir cambios no deseados. Para cambios de fondo y correcciones de carteles, establece low explícitamente. Reserva medium o high para texto denso, diseños complejos y escenas con muchos elementos restringidos.

El marcado de imágenes llega a POST /v1/images/edits como un campo markup. Envías una superposición transparente que rodea el objetivo y luego describes el cambio en prompt. El ejemplo de OpenAI rodea un jarrón, lo recolorea y pide al modelo que elimine el círculo de la foto final. El marcado también funciona en los modelos 2.5 compatibles, cuesta lo mismo que otras ediciones y no está disponible a través de la API de Responses, donde la guía te remite a las máscaras.

Precios de GPT-Image-2.6: mismas tarifas, más tokens con calidad low

Los precios por token coinciden con 2.5 en la página de precios: $8 por 1M de tokens de entrada de imagen, $2 en caché, $30 de salida, $5 de entrada de texto, $1,25 de texto en caché. Lo que cambió es el uso de tokens. La calculadora de OpenAI aplica un multiplicador de 4,2 con low y de 3,3 con medium para 2.6, y ninguno por encima de eso.

Calidad (1024x1024)	Tokens en 2.5	Coste de salida en 2.5	Tokens en 2.6	Coste de salida en 2.6
`low`	196	$0.00588	823	$0.02469
`medium`	439	$0.01317	1,449	$0.04347
`high`	1,756	$0.05268	1,756	$0.05268
`xhigh`	3,122	$0.09366	3,122	$0.09366
`max`	7,024	$0.21072	7,024	$0.21072

Estas cifras provienen de la calculadora y excluyen los tokens de entrada. El formato horizontal es más barato: low a 1536x1024 usa 664 tokens, unos $0,02.

Así que si ejecutas trabajos de gran volumen con low en 2.5, pasarte a 2.6 multiplica tu factura de salida por aproximadamente 4,2. medium en 2.6 ahora cuesta casi lo mismo que high, lo que hace que valga la pena probar high. La pestaña Batch de la página de precios incluye 2.5 a mitad de precio, pero no incluye 2.6, por lo que una carga de trabajo por lotes puede salir más barata en 2.5 por ahora. La guía tampoco incluye una fórmula de facturación específica para GIF, así que haz una prueba con un frame_count pequeño y revisa tu consumo antes de escalar. Nuestra guía de la API de gpt-image-2.5 cubre los conceptos básicos de las solicitudes que siguen aplicando.

Seguridad y procedencia

OpenAI probó ambos modelos con 3077 prompts adversarios. Esos resultados no son tasas de producción. La proporción de generaciones inseguras no bloqueadas pasó del 1,92% al 1,72% en Sunburst, y del 1,49% al 2,14% en Flare, aunque OpenAI no marca ninguno de los dos cambios como estadísticamente significativo.

Los GIF conllevan un riesgo nuevo, ya que el daño puede aparecer a lo largo de los fotogramas en lugar de en una sola imagen fija. OpenAI reporta un 77,7% de recall de moderación en un conjunto adversario de GIF, y afirma que las infracciones relacionadas con el movimiento siguen siendo difíciles de detectar.

En cuanto a la procedencia, Images 2.6 utiliza metadatos C2PA más una marca de agua invisible de SynthID en ChatGPT, Codex y la API.

Deja que tu agente de código lo pruebe con Apidog CLI

Esta versión cambió el uso de tokens sin cambiar la tarifa. Una prueba guardada detecta un cambio incompatible en una solicitud de la que dependes, y tu agente de código puede escribirla con Apidog CLI. Configúralo una vez:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
apidog skill install

Luego dale un prompt a Claude Code, Codex o Cursor:

Add POST https://api.openai.com/v1/images/generations to Apidog project <id>.
Create a test case that sends model gpt-image-2.6-flare, quality low,
complexity low, output_format gif and frame_count 6, with the Bearer [REDACTED]
read from the OPENAI_API_KEY environment variable. Assert status 200 and that
data[0].b64_json exists. Run it against environment <envId> and summarize failures.

El agente lee cada esquema, valida su payload y luego escribe y ejecuta la prueba:

apidog cli-schema get endpoint-create
apidog cli-schema validate endpoint-create --file endpoint.json
apidog endpoint create --project <id> --file endpoint.json
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <envId> \
  --env-var "OPENAI_API_KEY=$OPENAI_API_KEY" -r cli,json

Cada ejecución genera una imagen real y facturable, así que mantén bajos el número de fotogramas y la calidad. Duplica el caso con gpt-image-2.6-sunburst para comparar ambos modelos. Cambia -r cli,json por -r junit para ejecutarlo en un pipeline de CI, y consulta la guía de configuración de Claude Code para más detalles sobre agentes.

Preguntas frecuentes

¿ChatGPT Images 2.6 es gratis? OpenAI afirma que está disponible en todos los niveles de suscripción, y la página de precios indica generación de imágenes limitada en el plan Free. Ninguna de las dos fuentes da una cuota de GIF para los usuarios de Free. El uso de la API se factura por token.

¿La API devuelve un GIF o una hoja de sprites? Un GIF terminado. Establece output_format: "gif" en el endpoint de generaciones y luego decodifica b64_json. Las hojas de sprites del anuncio de lanzamiento provienen de prompts de ejemplo.

¿GPT-Image-2.6 es más caro que 2.5? Las tarifas por token coinciden, pero las imágenes con low y medium usan más tokens. Una imagen low de 1024x1024 pasa de unos $0,006 a unos $0,025 en coste de salida. high, xhigh y max no cambian.

¿Cuál es la diferencia entre quality y complexity? quality controla el detalle del renderizado y determina el coste en tokens. complexity controla cuánto planifica el modelo y su valor predeterminado es high. OpenAI sugiere complejidad low para la mayoría de las ediciones.

¿Puedo convertir una imagen existente en un GIF o SVG a través de la API? No. El endpoint de ediciones no admite salida GIF ni SVG, y los archivos SVG no se aceptan como entradas raster. Ambos formatos provienen únicamente del endpoint de generaciones.

Cómo usar la API de GPT-Image-2.6

Roobia — Thu, 05 Nov 2026 10:42:54 +0000

Cómo usar la API de GPT-Image-2.6

La API de GPT-Image-2.6 genera y edita imágenes mediante dos modelos de OpenAI, gpt-image-2.6-flare y gpt-image-2.6-sunburst. Envía un prompt a POST /v1/images/generations con tu clave de API y luego decodifica b64_json de la respuesta. La versión 2.6 incorpora marcado sobre imágenes, salida en SVG y GIF, y un parámetro complexity.

Prueba Apidog hoy

Esta guía abarca la autenticación, una primera generación, una edición con marcado, la exportación a SVG y la configuración de quality y complexity. Nos centramos en lo nuevo, así que consulta nuestra guía de la API de gpt-image-2.5 para streaming y la herramienta de la Responses API, y nuestro artículo explicativo sobre ChatGPT Images 2.6 para conocer todos los detalles del lanzamiento. Todas las peticiones que verás a continuación las elaboramos a partir de la documentación de OpenAI del 5 de noviembre de 2026. No las hemos ejecutado con una clave real, así que pruébalas antes de llevarlas a producción.

La API de GPT-Image-2.6 de un vistazo

Elemento	Detalle
IDs de modelo	`gpt-image-2.6-flare`, `gpt-image-2.6-sunburst`
Generación	`POST /v1/images/generations`
Edición	`POST /v1/images/edits`
Autenticación	`Authorization: Bearer $OPENAI_API_KEY`
Salida	`b64_json`; PNG por defecto, además de JPEG, WebP, GIF y SVG
`quality`	`low`, `medium`, `high`, `xhigh`, `max`, `auto` (por defecto)
`complexity`	`low`, `medium`, `high` (`high` si se omite)
Tarifas de tokens de imagen	$8 de entrada, $2 de entrada en caché, $30 de salida por 1M
Tarifas de tokens de texto	$5 de entrada, $1.25 de entrada en caché por 1M

Las tarifas provienen de la página de precios de OpenAI. Ambos modelos cuestan lo mismo por token, así que elige en función de la velocidad y la precisión de edición.

Flare o Sunburst: ¿qué modelo deberías usar?

Usa Flare para iterar rápido y para generaciones del día a día. OpenAI afirma que puede devolver una imagen en tan solo seis segundos con calidad low y que mejora la composición en pósteres e imágenes de producto. Usa Sunburst para trabajos detallados y ediciones repetidas, donde OpenAI asegura una mayor consistencia con calidad medium o high.

Estas son afirmaciones de OpenAI, no benchmarks independientes. Nuestra comparativa entre Flare y Sunburst para la versión 2.5 explica esta diferencia.

Autenticación y configuración

Necesitas tres cosas antes de tu primera llamada:

Crea una clave de API en el panel de OpenAI y expórtala como OPENAI_API_KEY.
Completa la verificación de organización de la API si tu organización lo requiere. OpenAI indica que es posible que tengas que hacerlo antes de poder usar los modelos GPT Image.
Instala jq para los ejemplos con curl, o el paquete openai para Python.

Si tu aplicación da servicio a usuarios individuales, envía también un safety_identifier con hash de hasta 128 caracteres. Sustituye al parámetro user, que está obsoleto.

Genera tu primera imagen

Esta petición usa Flare con calidad low, ideal para borradores.

curl --fail-with-body --silent --show-error \
  https://api.openai.com/v1/images/generations \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2.6-flare",
    "prompt": "A minimal poster for a developer meetup, with the words SHIP IT in bold type",
    "size": "1024x1536",
    "quality": "low",
    "complexity": "low"
  }' | jq -er '.data[0].b64_json' | base64 --decode > poster.png

La misma llamada en Python:

import base64
from pathlib import Path
from openai import OpenAI

client = OpenAI()

result = client.images.generate(
    model="gpt-image-2.6-sunburst",
    [REDACTED PROMPT],
    size="1536x1024",
    quality="medium",
    extra_body={"complexity": "low"},
)

Path("mug.png").write_bytes(base64.b64decode(result.data[0].b64_json))

Pasamos complexity a través de extra_body para que la llamada no dependa de que tu versión del SDK lo exponga como argumento con nombre. Los modelos GPT Image siempre devuelven base64, así que no envíes response_format ni busques un campo url.

La guía de OpenAI recomienda leer el objeto usage de la respuesta para medir el uso de tokens. No obstante, la referencia de la API describe ese campo como exclusivo de gpt-image-1, aunque su respuesta de ejemplo lo incluya, así que confirma que aparece en tus respuestas de la 2.6 antes de basar en él tu seguimiento de costes.

Edita una imagen con marcado

El marcado le indica al modelo dónde debe hacer un cambio. Envías la imagen original, un PNG transparente con tus círculos o bocetos, y un prompt que describe la edición.

curl --fail-with-body --silent --show-error \
  https://api.openai.com/v1/images/edits \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2.6-flare",
    "images": [{"image_url": "https://your-bucket.example/kitchen.png"}],
    "markup": {"image_url": "https://your-bucket.example/vase-overlay.png"},
    "prompt": "Recolor the vase inside the red circle to solid cobalt blue. Keep everything else unchanged. Remove the red circle.",
    "quality": "medium",
    "complexity": "low"
  }' | jq -er '.data[0].b64_json' | base64 --decode > vase.png

Las peticiones JSON usan el array images y un objeto markup que contiene exactamente uno de estos campos: image_url o file_id. Un image_url puede ser una URL HTTPS o una URL de datos en base64. Las peticiones multipart aceptan en su lugar una carga de archivo, y la guía de generación de imágenes incluye esa versión en Python.

La superposición tiene reglas estrictas:

Tras aplicar la orientación, debe coincidir con el ancho y el alto de la primera imagen.
Debe contener píxeles transparentes, así que no la aplanes sobre la foto.
Se aplica a la primera imagen de entrada. Cualquier otra actúa como referencia.
Cada una de las dos imágenes puede tener como máximo 16.777.216 píxeles, y el archivo de superposición no puede superar los 50 MB.
No puedes combinar markup con mask ni con prompt_rewriter.

Indícale al modelo que elimine la anotación, tal como hace el propio ejemplo de OpenAI. El marcado cuesta lo mismo que cualquier otra edición. La Responses API no lo admite, así que ahí tendrás que usar una máscara.

Exporta a SVG

Configura output_format como svg en el endpoint de generaciones para iconos, logotipos e ilustraciones que necesiten trazados editables.

curl --fail-with-body --silent --show-error \
  https://api.openai.com/v1/images/generations \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2.6-sunburst",
    "prompt": "A flat two-color wheat logo for a bakery called Field and Flour",
    "output_format": "svg",
    "quality": "medium",
    "n": 1
  }' | jq -er '.data[0].b64_json' | base64 --decode > logo.svg

La API primero genera una imagen de referencia, que quality controla, y luego escribe el SVG a partir de ella. Los bytes decodificados son XML en UTF-8, sin scripts, recursos externos ni rásteres incrustados.

Se aplican cuatro límites:

n debe ser 1.
El streaming, las imágenes parciales, output_compression y prompt_rewriter no funcionan.
El endpoint de ediciones no puede generar SVG, y no aceptará un SVG como entrada ráster.
El objeto opcional svg elige el modelo de autoría, pero solo si tu cuenta tiene selección de modelo SVG. De lo contrario, omítelo.

Pagas dos veces: la tarifa de imagen por la imagen de referencia y la tarifa del modelo de autoría por sus tokens. La referencia de la API incluye un objeto svg_usage aparte para esa segunda parte, así que regístralo.

Genera un GIF

La API devuelve un GIF terminado, no una hoja de sprites. Añade tres campos a una petición de generaciones:

{
  "model": "gpt-image-2.6-flare",
  "prompt": "A small orange robot waves, blinks and returns to its starting pose. Make it loop.",
  "output_format": "gif",
  "frame_count": 9,
  "frame_duration_ms": 200,
  "size": "auto"
}

Decodifica b64_json de la misma forma y guárdalo como .gif. Antes, comprueba dos cosas:

Límite de fotogramas. La guía indica que frame_count va de 2 a 64. La referencia de la API dice de 2 a 16. Quédate en 16 o menos hasta que hayas probado valores superiores.
Acceso. La referencia indica que la salida GIF requiere acceso a la vista previa de GIF del modelo seleccionado, mientras que la guía no lo menciona. Una petición de GIF rechazada puede deberse a un problema de acceso, no a un payload incorrecto.

La salida GIF no admite streaming, imágenes parciales ni output_compression personalizado, y el endpoint de ediciones no puede devolverla. OpenAI no publica una fórmula de facturación específica para GIF, así que haz una prueba pequeña y revisa tu factura antes de escalar.

Configura quality y complexity

quality controla el nivel de detalle del renderizado e influye en el coste de tokens. complexity controla cuánto planifica el modelo antes de renderizar, y cambiarlo no conlleva ningún cargo adicional.

Configura complexity en cada petición. El valor por defecto es high, pero OpenAI recomienda low para la mayoría de las ediciones. La guía advierte de que los valores más altos pueden aumentar la latencia e introducir cambios no deseados.

La calidad también determina tu factura de salida. Esta tabla usa la calculadora de OpenAI para una imagen de 1024x1024, consultada el 5 de noviembre, y excluye los tokens de entrada:

`quality`	Tokens de salida	Coste de salida
`low`	823	$0.02469
`medium`	1,449	$0.04347
`high`	1,756	$0.05268
`xhigh`	3,122	$0.09366
`max`	7,024	$0.21072

La diferencia entre medium y high es de aproximadamente un centavo, así que compara ambos. La pestaña Batch de la página de precios aún no incluye la 2.6, así que no des por hecho que se aplica el descuento por lotes de la 2.5.

Gestiona errores y tiempos de espera

Clasifica los fallos según si un reintento puede ayudar:

Fallo	Qué hacer
Límite de tasa o error del servidor	Reintentar con retroceso exponencial
Error de cuota	No reintentar; solucionar la facturación
`error.type` es `image_generation_user_error`	Cambiar primero el prompt o la entrada
`error.code` es `moderation_blocked`	Leer `moderation_details` y luego revisar

Usa error.code como tu comprobación estable y registra el ID de la petición. moderation_details incluye moderation_stage y categories generales, que deben ir en tus logs, no en los mensajes dirigidos al usuario. Configura tiempos de espera del cliente superiores a dos minutos, porque OpenAI indica que los prompts complejos pueden tardar tanto.

Deja que tu agente de programación lo pruebe con Apidog CLI

Tu agente de programación puede convertir estas peticiones y límites en un conjunto de pruebas con Apidog CLI. Configúralo una vez:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
apidog skill install

Después, dale un prompt a Claude Code, Codex o Cursor:

In Apidog project <id>, add POST /v1/images/generations and POST /v1/images/edits
on https://api.openai.com. Read the Bearer [REDACTED] from OPENAI_API_KEY.
Create test cases for gpt-image-2.6-flare at low quality and low complexity:
1. PNG generation: assert status 200 and data[0].b64_json exists.
2. SVG generation: assert status 200 and output_format equals svg.
3. GIF with frame_count 6: assert status 200 and output_format equals gif.
4. SVG with n set to 2: assert a 4xx status and that error.message exists.
5. GIF with frame_count 17: record the status, because OpenAI's docs disagree.
Put them in a test suite named "GPT-Image-2.6", run it against environment
<envId>, and summarize every failure.

El agente lee cada esquema, valida su payload y luego escribe y ejecuta el conjunto de pruebas:

apidog cli-schema get endpoint-create
apidog cli-schema validate endpoint-create --file endpoint.json
apidog endpoint create --project <id> --file endpoint.json
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog cli-schema validate test-suite-create --file suite.json
apidog test-suite create --project <id> --file suite.json
apidog test-suite run <suiteId> --project <id> -e <envId> \
  --env-var "OPENAI_API_KEY=$OPENAI_API_KEY" --on-error continue -r cli,json

El caso 5 determina el límite de fotogramas para tu cuenta, y el caso 3 muestra si tienes acceso a GIF. Los casos que se ejecutan correctamente generan imágenes reales y facturables, así que mantén la calidad baja. Cambia a -r junit para ejecutar el conjunto en un pipeline de CI, y consulta la guía de configuración de Claude Code para más detalles sobre el agente.

Preguntas frecuentes

¿Cuáles son los nombres de los modelos de la API de GPT-Image-2.6? gpt-image-2.6-flare y gpt-image-2.6-sunburst. La referencia de la API aún no incluye instantáneas con fecha para ellos, a diferencia de los modelos 2.5.

¿Cuánto cuesta la API de GPT-Image-2.6? Los tokens de imagen cuestan $8 por 1M de entrada y $30 por 1M de salida. Una imagen de 1024x1024 cuesta unos $0.025 de salida con low y unos $0.053 con high, sin contar los tokens de entrada.

¿Debería migrar desde gpt-image-2.5? Migra si necesitas SVG, GIF o complexity. Prueba antes tus costes: una imagen en low usa aproximadamente 4,2 veces los tokens que usaba en la 2.5, y los modelos 2.6 aún no tienen precios por lotes publicados.

¿Puedo usar complexity en el endpoint de ediciones? Sí. OpenAI recomienda low para la mayoría de las ediciones.

¿Puedo convertir una imagen subida en un GIF a través de la API? No. El endpoint de ediciones no devuelve GIF ni SVG, así que ambos formatos parten de un prompt de texto en el endpoint de generaciones.

¿La API devuelve una URL? No. Los modelos GPT Image siempre devuelven base64 en b64_json, así que decodifícalo y guarda el archivo tú mismo.

Cómo detectar vulnerabilidades en tu repositorio gratis

Roobia — Thu, 05 Nov 2026 09:01:14 +0000

Cómo detectar vulnerabilidades en tu repositorio gratis

Para detectar vulnerabilidades en tu repositorio de forma gratuita, combina tres capas: un escáner de dependencias (npm audit, pip-audit o OSV-Scanner), un escáner de secretos (Gitleaks) y un escáner de código (Semgrep Community Edition). Ejecútalos en cada pull request. Ninguno de ellos detectará la falta de una comprobación de autorización, por lo que conviene añadir una prueba en tiempo de ejecución para cubrir ese caso.

Prueba Apidog hoy

npm audit --audit-level=high
pip-audit -r requirements.txt
gitleaks git . --no-banner
semgrep scan --config p/default --metrics=off --error

Qué cambia con Vercel Security Review

Vercel Security Review es una funcionalidad de Vercel Agent, en beta pública desde el 2 de noviembre de 2026. Analiza cada push en un repositorio de GitHub conectado, examina el diff y el código adyacente, rastrea cómo se puede alcanzar el cambio y verifica de nuevo cada hallazgo antes de reportarlo.

El ejemplo de Vercel es el motivo por el que existe este artículo. Un cambio en un endpoint de facturas buscaba facturas por ID sin comprobar la organización, lo que permitía a cualquier usuario autenticado descargar la factura de otra organización. Se trata de un error de lógica, y los escáneres basados en patrones tienen dificultades para detectar este tipo de fallos.

A continuación se detalla quién puede utilizarlo:

Pregunta	Respuesta
Planes	Solo para equipos Pro y Enterprise
Coste	Gratis hasta el 10 de noviembre de 2026; después, las tarifas por token del proveedor más 0,25 $ por millón de tokens
Repositorios	Repositorios de GitHub conectados; los repositorios que no se despliegan en Vercel aún no son compatibles
Alcance	El diff respecto a una base, o el código fuente completo en la primera revisión
Hallazgos	Panel de vulnerabilidades, un GitHub check y comentarios en los PR en repositorios privados e internos

La documentación de Vercel también señala sus límites: analiza código, no la aplicación en ejecución, y no sustituye a una prueba de penetración. Si no cumples los requisitos o estás leyendo esto después del periodo gratuito, el resto de esta guía no te costará nada.

Qué debería cubrir un escaneo de vulnerabilidades en el repositorio

Un escaneo exhaustivo de vulnerabilidades en un repositorio evalúa cuatro aspectos: vulnerabilidades conocidas en las dependencias, credenciales subidas a Git, patrones de código inseguros como inyecciones y la lógica de autorización. Los tres primeros cuentan con escáneres gratuitos y consolidados. El cuarto depende del comportamiento semántico del código, por lo que requiere una prueba contra una API en ejecución.

Una clave eliminada permanece en el historial de Git, así que analiza el historial y rota cualquier clave real. Para detectar claves en el tráfico de la API y en colecciones de pruebas, consulta nuestra guía para detectar fugas de claves de API.

Comparativa de escáneres de vulnerabilidades gratuitos

Los precios y las licencias se verificaron el 5 de noviembre de 2026. Ninguna de las herramientas de línea de comandos requiere una cuenta ni tarjeta de crédito para los comandos que se muestran en esta guía.

Herramienta	Qué detecta	Coste y licencia	Aspectos a tener en cuenta
`npm audit`	Vulnerabilidades en dependencias de npm	Gratuito, incluido con npm	Requiere un archivo lockfile
pip-audit	Vulnerabilidades en dependencias de Python	Gratuito, Apache-2.0	Solo para Python
OSV-Scanner	Vulnerabilidades en dependencias de múltiples ecosistemas	Gratuito, Apache-2.0	Reporta más resultados, por lo que requerirá triaje
Trivy	Dependencias, secretos y errores de configuración	Gratuito, Apache-2.0	Fijar versiones (ver más abajo)
Gitleaks	Secretos en el historial de Git	Gratuito, MIT	Su GitHub Action requiere una clave de licencia gratuita para organizaciones
Semgrep Community Edition	Patrones de código y algunos secretos	Gratuito, motor con licencia LGPL-2.1	No puede rastrear datos más allá de una sola función o archivo
Alertas de Dependabot	Vulnerabilidades en dependencias	Gratuito en repositorios públicos y privados	Solo para GitHub
Escaneo de secretos de GitHub	Secretos	Gratuito en repositorios públicos; 19 $ al mes por committer activo en privados	Los repositorios privados requieren Secret Protection
CodeQL	Patrones de código	Gratuito en repositorios públicos; 30 $ al mes por committer activo en privados	Los repositorios privados requieren Code Security

Dos apuntes sobre licencias. Las reglas comunitarias de Semgrep utilizan la Semgrep Rules License, que autoriza el uso interno comercial, pero no su redistribución ni su oferta como servicio. Y si vas a adoptar Trivy, revisa CVE-2026-33634: en marzo de 2026 se comprometieron brevemente partes del ecosistema de Trivy. Utiliza una versión actualizada y fija cualquier GitHub Action al SHA de un commit.

Escanear un repositorio con pocos comandos: lo que encontramos

Construimos una pequeña API de facturación con Express y la subimos a un repositorio local. Contaba con cuatro dependencias de npm y tres de Python en versiones antiguas, dos claves simuladas (una al estilo de Stripe y otra al estilo de AWS), una inyección SQL, una inyección de comandos y una ruta que devuelve la factura de cualquier organización a cualquier usuario autenticado.

A continuación, ejecutamos cada herramienta en macOS el 5 de noviembre de 2026:

npm audit
pip-audit -r requirements.txt --no-deps --disable-pip
osv-scanner scan source -r .
trivy fs --scanners vuln,secret .
gitleaks git . --no-banner
semgrep scan --config p/default --metrics=off
semgrep scan --config p/nodejsscan --metrics=off

Herramienta (versión)	Detectado	No detectado
`npm audit` (npm 11.12.1)	9 paquetes vulnerables: 6 de severidad alta, 3 baja	Todo lo que no sea un paquete de npm
pip-audit 2.10.1	16 avisos de seguridad en los 3 paquetes fijados	Paquetes transitivos, debido a que usamos `--no-deps`
OSV-Scanner 2.7.0	66 avisos únicos en 15 paquetes, incluidos los paquetes transitivos de Python	Secretos y errores de código
Trivy 0.76.1	33 vulnerabilidades en dependencias y la clave al estilo de Stripe	La clave al estilo de AWS
Gitleaks 8.30.1	La clave al estilo de Stripe	La clave al estilo de AWS
Semgrep 1.183.0, `p/default`	Clave al estilo de Stripe, inyección de comandos y un aviso por ausencia del middleware de CSRF	Inyección SQL, clave al estilo de AWS
Semgrep 1.183.0, `p/nodejsscan`	Inyección SQL, inyección de comandos y clave al estilo de AWS	Clave al estilo de Stripe

Destacan tres conclusiones:

Las cifras no son comparables. Un paquete, un aviso de seguridad y un hallazgo son métricas distintas, y cada herramienta analiza datos diferentes. Compara lo que se detectó, no los totales.
Un solo escáner de secretos no basta. Tanto Gitleaks como Trivy pasaron por alto la clave al estilo de AWS.
Los conjuntos de reglas marcan la diferencia. El paquete predeterminado de Semgrep no detectó una consulta SQL construida mediante concatenación simple de cadenas. p/javascript, p/nodejs, p/owasp-top-ten y p/sql-injection no devolvieron nada en este repositorio, mientras que p/nodejsscan sí la encontró.

Ninguna herramienta señaló la ruta de facturas. Este es solo un repositorio pequeño, así que tómalo como una demostración y no como un benchmark formal. No ejecutamos CodeQL.

Analiza tu repositorio de GitHub en cada pull request

Los ejecutores estándar alojados en GitHub son gratuitos en repositorios públicos. En repositorios privados, GitHub Free incluye un saldo mensual de 12 $, lo que equivale a unos 2000 minutos en un ejecutor Linux de 2 núcleos según la tarifa establecida. Este flujo de trabajo utiliza comandos estándar, por lo que las organizaciones pueden prescindir de la clave de licencia de la GitHub Action de Gitleaks:

name: repo-scan
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7 # pin to a commit SHA
        with:
          fetch-depth: 0
      - name: Dependencies (npm)
        run: npm audit --audit-level=high
      - name: Dependencies (Python)
        run: pipx run pip-audit -r requirements.txt
      - name: Secrets
        run: |
          curl -sSL https://github.com/gitleaks/gitleaks/releases/download/v8.30.1/gitleaks_8.30.1_linux_x64.tar.gz | tar xz gitleaks
          ./gitleaks git . --no-banner
      - name: Code patterns
        run: pipx run semgrep scan --config p/default --config p/nodejsscan --metrics=off --error

Los cuatro escáneres finalizaron con código de salida 1 en nuestro repositorio de prueba, y una salida distinta de cero es lo que hace fallar el job. Elimina los pasos que tu stack no necesite. Para integrar pruebas de API en la misma pipeline, consulta Apidog CLI con GitHub Actions.

Activa también las alertas de Dependabot. Son gratuitas en todos los planes y no esperan a que haya un pull request para avisarte.

La brecha: fallos de autorización que los escáneres pasan por alto

Los fallos de autorización resultan difíciles de detectar para los escáneres de patrones porque el código parece correcto a simple vista: una consulta válida, un parámetro válido y un middleware de auth protegiendo la ruta. El fallo reside en una condición ausente, y únicamente tu modelo de datos determina que dicha condición debería existir.

// Every scanner passed this
db.query("SELECT * FROM invoices WHERE id = $1", [req.params.id]);

// The fix: scope the lookup to the caller's organization
db.query("SELECT * FROM invoices WHERE id = $1 AND org_id = $2",
  [req.params.id, req.user.orgId]);

Se trata de Broken Object Level Authorization (BOLA), clasificada en el primer puesto del OWASP API Security Top 10 2023. OWASP recomienda validar los permisos de acceso en cada petición que utilice un ID proporcionado por el cliente y escribir pruebas que detecten fallos de autorización antes del despliegue.

Recurrir a un agente de código resulta útil. Eliminamos los comentarios del repositorio de prueba y le pedimos a Claude Code que lo revisara, con y sin una pista sobre las organizaciones. Detectó la ruta de facturas en ambas ocasiones. No obstante, no es una alternativa con coste cero por sí misma, ya que consume el plan de tu agente y los resultados pueden variar entre ejecuciones.

Una prueba ofrece una respuesta binaria (pasa o falla) en cada pull request. Para asegurar una cobertura adecuada a nivel de API, consulta la detección automatizada de vulnerabilidades en API, nuestra recopilación de herramientas de escaneo de seguridad de API y la lista de comprobación para pruebas de seguridad de API.

Permite que tu agente de código pruebe la autorización con Apidog CLI

No escribas esta prueba manualmente para cada ruta. Deja que tu agente de código se encargue utilizando Apidog CLI: lee tus rutas, crea una prueba por cada recurso protegido y genera una suite lista para ejecutarse en CI. Apidog Free cubre hasta 4 usuarios.

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
apidog skill install

Necesitarás un entorno de pruebas con dos organizaciones creadas con datos iniciales y un usuario en cada una. Luego, proporciónale este prompt a tu agente:

Read the routes in src/. For each route that returns data owned by an
organization, create an Apidog test scenario in project <id>: log in as
the Org A test user, request an Org B resource by ID, and assert the
status is 403 or 404. Add an Org A request for its own resource and
assert 200, so a broken login can't pass. Group the scenarios in a test
suite, run it against the staging environment, and summarize failures.

El agente comprueba la estructura del payload, crea los escenarios y ejecuta la suite:

apidog cli-schema get test-scenario-create
apidog cli-schema validate test-scenario-create --file scenario.json
apidog test-scenario create --project <id> --file scenario.json
apidog test-scenario import-steps <scenarioId> --project <id> --source endpoint --ids <endpointIds>
apidog test-suite create --project <id> --file suite.json
apidog run --test-suite <suiteId> --project <id> -e <envId> -r cli,junit

La comprobación positiva es fundamental. Sin ella, una URL base incorrecta también devolvería un 404 y la prueba pasaría por el motivo equivocado.

Añade la misma línea con apidog run al flujo de trabajo anterior, ejecutándola contra un despliegue de preview o staging con organizaciones de prueba precargadas, nunca con datos de producción. La referencia del comando apidog run cubre el resto de parámetros, y la guía de Apidog CLI en Claude Code explica paso a paso la configuración del agente.

Preguntas frecuentes

¿Cuál es la mejor forma gratuita de detectar vulnerabilidades en un repositorio? Combina un escáner de dependencias, Gitleaks y Semgrep Community Edition, y añade además una prueba en tiempo de ejecución para la autorización. Ninguna herramienta por sí sola cubrió todo en nuestro repositorio de prueba.

¿Es gratuito Vercel Security Review? Solo hasta el 10 de noviembre de 2026 y únicamente para equipos Pro y Enterprise. A partir de esa fecha, se pagan las tarifas por token del proveedor más 0,25 $ por millón de tokens. Los repositorios que no se despliegan en Vercel aún no son compatibles.

¿El escaneo de secretos de GitHub es gratuito en repositorios privados? No. Tanto el escaneo de secretos como CodeQL son gratuitos en repositorios públicos, pero los repositorios privados requieren GitHub Secret Protection (19 $) o GitHub Code Security (30 $) por committer activo al mes. Las alertas de Dependabot son gratuitas en ambos.

¿Puede Semgrep detectar fallos de autorización? No detectó nuestra ruta de facturas con los conjuntos de reglas que ejecutamos. Community Edition no puede rastrear el flujo de datos más allá de una sola función o archivo, aunque es posible escribir reglas personalizadas para patrones específicos de tu base de código.

¿Reemplazan los escáneres una prueba de penetración? No. Los escáneres y las pruebas cubren patrones conocidos y los casos de prueba definidos. Una prueba de penetración busca aquello que no se ha previsto, y la propia documentación de Vercel aclara que su análisis tampoco constituye un pentest.

¿Qué es Chain of Recall? Cómo los IDs estables dan memoria a los agentes de IA

Roobia — Thu, 05 Nov 2026 07:05:24 +0000

¿Qué es Chain of Recall? Cómo los IDs estables dan memoria a los agentes de IA

Chain of Recall es una forma de dotar de memoria a un agente de IA de larga ejecución sin saturar su ventana de contexto. Cada Trigger, Thread y Worker recibe un ID estable. El contexto solo conserva los IDs, resúmenes breves y mensajes cercanos, y el agente recorre los enlaces entre identificadores para recuperar hechos anteriores en unos pocos saltos.

Prueba Apidog hoy

El término proviene del ensayo de diseño de DeepSeek Harness “Exploring Super-agent Design”, publicado el 01-11-2026. Una advertencia antes de continuar: el ensayo describe una arquitectura, no una funcionalidad lanzada al mercado. Parte de ella reside en un plugin prototipo, dsh-superagent-prototype, que los autores definen como «no es un producto oficial de DeepSeek». No existe ningún interruptor para activar Chain of Recall: es un patrón que debes construir.

El problema de la ventana de contexto en un agente de larga ejecución

Un agente de larga ejecución alcanza su límite de contexto porque el flujo de trabajo nunca se detiene. Un superagente que monitoriza el chat, GitHub y CI procesa cientos de eventos al día, y la ventana que albergó el trabajo de ayer no puede contener también el de hoy.

Las soluciones habituales conllevan un coste:

Conservar todo. La ventana se llena y el coste se dispara con cada turno.
Resumir turnos antiguos. Un resumen suele descartar el error exacto o el número de PR que necesitarás más adelante.
Recuperar por similitud. Funciona hasta que el dato que buscas no se parece a tu consulta.

La guía de Anthropic sobre ingeniería de contexto para agentes de IA plantea el contexto como un recurso finito que se debe curar. Chain of Recall es una forma concreta de llevar a cabo esa curación, y nuestra guía explicativa sobre cómo funciona la memoria en los agentes de IA analiza un abanico más amplio de opciones.

Inline frente a spill: el contexto como una memoria caché

El ensayo aborda la ventana de contexto como una memoria caché con dos acciones:

Inline para lo que el agente probablemente necesite de inmediato: identificadores, resúmenes breves y mensajes cercanos.
Spill para todo lo demás: truncarlo y dejar un puntero que el agente pueda consultar más tarde.

Un elemento derivado a spill no se elimina; únicamente su puntero permanece en el prompt.

Así se vería el fallo de una integración continua (CI) que llega al Router. Esta estructura es meramente ilustrativa, no es código de DeepSeek:

{
  "trigger_id": "trg_8f21",
  "source": "github.check_run",
  "thread_id": "thr_pr_412",
  "summary": "CI failed on PR #412: 3 of 118 tests red in payments/",
  "neighbours": ["trg_8f1c: review comment asking for retry logic"],
  "spilled": {
    "full_log": "GET /triggers/trg_8f21/payload (41 KB, truncated)"
  }
}

Si el resumen de una sola línea es suficiente, el agente nunca asume el coste del registro de 41 KB. Si no lo es, recupera el log mediante su ID.

Identificadores estables y el grafo de referencias

Chain of Recall funciona porque los ID nunca cambian. En el diseño planteado por el ensayo, tres tipos de objetos los incorporan:

Objeto	Descripción	Ejemplo de ID
Trigger	Un evento entrante: un mensaje de chat, un webhook, una devolución de llamada de CI	`trg_8f21`
Thread	Una secuencia de eventos relacionados en un PR, tema de mensajería o hilo de correo electrónico	`thr_pr_412`
Worker	Una sesión de agente aislada que gestiona una sola tarea	`wkr_77a0`

Un Trigger pertenece a un Thread, un Thread es propiedad de uno o más Workers, y el informe de un Worker cita los Triggers sobre los que actuó. Estos vínculos forman un grafo de referencias, y dicho grafo constituye la memoria del agente.

La recuperación de información se lleva a cabo siguiendo los enlaces salto a salto, en lugar de cargar todo el historial o buscar coincidencias de texto. La guía complementaria sobre cómo construir un superagente explica qué papel desempeñan los Triggers, Threads y Workers en el diseño completo de Router y Worker.

Ejemplo práctico de recuperación multisalto

Supongamos que un compañero le pregunta al Router un viernes: «¿Por qué añadimos la lógica de reintento al cliente de pagos?». La conversación original tuvo lugar el martes y se envió a spill hace mucho tiempo. Así se recorre la cadena:

Salto 1: localizar el Thread. El contexto del Router aún conserva una entrada de índice de una línea: thr_pr_412: payments retry PR, merged Wed. Ejecuta un GET /threads/thr_pr_412.
Salto 2: identificar el Worker. El registro del Thread incluye owner_workers: ["wkr_77a0"]. El Router realiza un GET /workers/wkr_77a0 y lee su informe final.
Salto 3: descubrir la causa. El informe cita trg_8f21, el fallo de CI. El Router obtiene la carga útil de ese Trigger y lee los errores de tiempo de espera (timeout) en el log.
Respuesta. «La CI en el PR #412 falló el martes por 3 tiempos de espera en los pagos. El Worker wkr_77a0 añadió reintentos con retroceso exponencial (backoff) y el PR se fusionó el miércoles».

Tres peticiones pequeñas y precisas. No se dedujo nada al azar ni hubo información ocupando espacio en el prompt durante tres días.

Chain of Recall frente a la memoria vectorial y los resúmenes

Chain of Recall no reemplaza a otras técnicas de memoria; responde a una pregunta diferente. La recuperación vectorial, popularizada por el artículo sobre generación aumentada por recuperación, plantea «¿qué se parece a esto?». Chain of Recall plantea «¿qué está vinculado a esto?».

	Chain of Recall	Memoria vectorial (RAG)	Resúmenes continuos	Servidores MCP de memoria
Mecanismo de recuperación	Sigue enlaces mediante identificadores estables	Búsqueda por similitud sobre embeddings	Lee un historial comprimido	Invoca una herramienta de memoria expuesta por el servidor
Precisión	Registro exacto por ID	Aproximada, clasificada por puntuación	Con pérdida por diseño	Depende del almacenamiento del servidor
Ideal para	Historiales de eventos: PR, tickets, ejecuciones de CI	Grandes volúmenes de documentos, consultas difusas	Sesiones cortas, continuidad en chats	Datos compartidos entre distintas herramientas y sesiones
Requisitos	Identificadores inmutables, API de consulta por ID	Un modelo de embeddings y un índice	Una pasada de resumen	Un servidor MCP en ejecución
Punto débil	No encuentra aquello que no esté vinculado	Pasa por alto hechos expresados con otras palabras	Omite detalles	Un servicio adicional que mantener y proteger

En la práctica, lo habitual es combinarlos: un índice vectorial identifica el ID del Thread inicial y, a partir de ahí, Chain of Recall avanza hasta los datos exactos. La jerarquía de memoria al estilo de un sistema operativo propuesta en el artículo de MemGPT es un concepto muy cercano. Si prefieres comenzar con una solución lista para usar, consulta nuestra guía sobre cómo añadir memoria persistente a agentes de IA con MCP.

Existen dos limitaciones. El ensayo sitúa la memoria a largo plazo entre los problemas aún abiertos y no afirma que Chain of Recall lo resuelva. Además, en su experimento, eliminar la transferencia directa de Threads (Thread pass-through) incrementó los tokens de lectura de caché de 23,2 M a 31,8 M por ejecución (alrededor de un 37 % más): se trata del coste asociado a una funcionalidad ausente, no de un ahorro atribuible a Chain of Recall.

Qué deben garantizar las API subyacentes

Cada salto en este recorrido corresponde a una llamada a la API. Si una llamada devuelve un registro diferente, o ninguno, la cadena se rompe y el agente se detiene o responde basándose en suposiciones. Por ello, las API que respaldan Chain of Recall deben cumplir cuatro contratos esenciales:

Los identificadores nunca cambian. Un ID devuelto hoy debe resolver el mismo objeto el mes que viene. Nada de reutilizarlos tras eliminarlos ni de renumerarlos tras una migración.
La consulta por ID es ligera y exacta. GET /threads/{id} devuelve ese único registro. No realiza búsquedas ni devuelve la «coincidencia más cercana».
Los identificadores desconocidos fallan de forma explícita. Un ID inexistente devuelve 404 Not Found, según lo define la norma RFC 9110, con un cuerpo de error claro. Un código 200 con un objeto vacío induciría al agente a creer que existe un recuerdo cuando no es así.
Los cursores paginan sin omisiones. GET /threads/{id}/events?cursor= recorre un Thread extenso en orden. Cada evento aparece exactamente una vez, no se salta ninguno y el cursor sigue siendo válido a medida que llegan nuevos eventos.

Estos contratos suelen romperse de forma silenciosa durante las refactorizaciones, por lo que deben formar parte de las pruebas automatizadas. Las respuestas de las herramientas también deben mantenerse compactas, un aspecto que abordamos en profundidad en nuestra guía sobre las respuestas de las herramientas del agente y la ventana de contexto.

Permite que tu agente de programación pruebe las API de recuperación con Apidog CLI

Chain of Recall es tan confiable como lo sean sus endpoints de consulta por ID, y un agente de programación puede escribir y volver a ejecutar esas validaciones por ti. Apidog CLI proporciona al agente comandos para definir los endpoints, crear casos de prueba y ejecutarlos directamente desde el terminal.

Configúralo una sola vez:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

A continuación, proporciona a Claude Code, Codex o cualquier agente que utilices el siguiente [REDACTED PROMPT]
In Apidog project , define three endpoints for our agent memory
service: GET /threads/{id}, GET /threads/{id}/events?cursor=, and
GET /workers/{id}. Then create test cases that check:

A thread_id returned by GET /threads/{id} resolves to the same record on a second call, and each owner worker ID resolves via GET /workers/{id}.
An unknown thread ID and an unknown worker ID both return 404.
Paging GET /threads/{id}/events with the cursor returns every event once, in order, with no gaps. Run them against the staging environment and summarize any failures.


El agente lee el esquema de cada payload, valida su JSON antes de escribir nada y, posteriormente, genera y ejecuta las pruebas:

bash
apidog cli-schema get endpoint-create
apidog cli-schema validate endpoint-create --file thread-get.json
apidog endpoint create --project --file thread-get.json

apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file id-resolves.json
apidog test-case create --project --file id-resolves.json

apidog run --test-case --project -e -r cli,json




El generador de informes `cli` muestra las aserciones superadas y fallidas en el terminal, y el reporte `json` proporciona al agente un archivo interpretable para identificar con precisión qué salto falló. Si un ID deja de resolverse tras una migración, lo verás reflejado en el informe antes de que el agente comience a responder basándose en una cadena rota. Para ejecutar estas mismas comprobaciones en cada merge, cambia el reporter a `-r junit`; nuestra guía sobre [Apidog CLI en Claude Code](https://apidog.com/es/blog/apidog-cli-in-claude-code?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) muestra el ciclo completo del agente.

## Dónde encaja Chain of Recall

Utiliza Chain of Recall cuando la memoria de tu agente consista en un historial de eventos discretos y enlazables: PR, tickets, ejecuciones de CI, hilos de soporte o despliegues. Estos elementos ya disponen de identificadores naturales, y las preguntas que los usuarios suelen formular sobre ellos («¿por qué hicimos esto?», «¿qué ocurrió después de aquello?») son cuestiones centradas en las conexiones entre dichos eventos.

Recurre a la recuperación vectorial para documentos no estructurados y preguntas difusas, y emplea resúmenes para sesiones breves en las que perder cierto nivel de detalle no suponga un inconveniente.

Chain of Recall surge de un ensayo y un prototipo: es una idea clara y contrastable, no un producto empaquetado. Para conocer la herramienta detrás de este ensayo, echa un vistazo a [qué es DeepSeek Harness](https://apidog.com/es/blog/what-is-deepseek-harness?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation).

## Preguntas frecuentes

**¿Es Chain of Recall una función de DeepSeek que pueda activar?**
No. Es un término extraído del ensayo sobre superagentes de DeepSeek Harness, y parte de su implementación reside en un plugin prototipo que los propios autores señalan que no es un producto oficial de DeepSeek. El patrón debe implementarlo uno mismo.

**¿Cuál es la diferencia entre inline y spill?**
Inline mantiene los identificadores, los resúmenes breves y los mensajes cercanos dentro del prompt. Spill trunca el resto y deja un puntero que el agente puede consultar por ID cuando lo necesite.

**¿Sustituye Chain of Recall a RAG?**
No. RAG localiza contenido similar, mientras que Chain of Recall sigue enlaces exactos a través de identificadores. Muchos agentes combinan ambos enfoques.

**¿Redujo Chain of Recall el consumo de tokens en un 37 %?**
No. La cifra del 37 % corresponde al Thread pass-through: en el experimento del ensayo, su eliminación provocó que los tokens de lectura de caché aumentaran de 23,2 M a 31,8 M por ejecución. El ensayo no atribuye un ahorro de tokens al propio Chain of Recall.

**¿Qué debe devolver una API de consulta por ID ante un identificador desconocido?**
Un error `404 Not Found` acompañado de un cuerpo explicativo claro. Devolver un `200` con un objeto vacío hace que el agente asuma que el registro existe, rompiendo silenciosamente la cadena de recuperación.

**¿Cómo puedo verificar que las API de memoria de mi agente permanezcan estables?**
Diseña casos de prueba que verifiquen que un ID obtenido en una llamada se resuelve en la siguiente, que los identificadores desconocidos devuelven un 404 y que los cursores paginan sin omisiones. Un agente de programación puede generar y ejecutar estas pruebas con Apidog CLI en cada merge.

Llamadas asíncronas a herramientas para agentes de IA: por qué start() supera a un run() bloqueante

Roobia — Thu, 05 Nov 2026 05:53:30 +0000

Llamadas asíncronas a herramientas para agentes de IA: por qué start() supera a un run() bloqueante

Respuesta rápida: Las llamadas asíncronas a herramientas para agentes de IA dividen un run() bloqueante en un pequeño contrato: start() devuelve de inmediato un identificador de la tarea, status() informa del progreso, stop() cancela y el resultado regresa más tarde como un evento que el agente lee en su siguiente turno. El agente sigue conversando y recibiendo nuevas instrucciones mientras las tareas lentas se ejecutan en segundo plano.

Prueba Apidog hoy

La mayoría de los agentes actuales llaman a una herramienta y se quedan esperando. Si haces una segunda pregunta durante la ejecución de una suite de pruebas de 6 minutos, esta se queda en cola. Esto no supone un problema para una consulta de 200 ms, pero resulta frustrante en un despliegue o en un rastreo web.

Un artículo reciente del equipo de DeepSeek Harness, "Exploring Super-agent Design", propone una solución denominada «full-duplex»: sustituir el run() bloqueante por start() y stop(). Esta guía aborda la perspectiva del bucle del agente: el contrato de las herramientas, cómo retornan los resultados, la cancelación y la API que requiere cada herramienta. Para conocer la gestión HTTP de una llamada individual de larga duración, consulta AI Agents and Long-Running API Calls: Polling vs Webhooks.

¿Qué son las llamadas asíncronas a herramientas en el bucle de un agente?

Una llamada asíncrona a una herramienta es una invocación que devuelve un identificador (handle) en lugar de un resultado inmediato. El bucle del agente registra dicho identificador, finaliza su turno y queda disponible para el usuario. Cuando el trabajo termina, el runtime inyecta un evento de finalización en la conversación y el modelo lo lee en su siguiente turno como cualquier otro mensaje.

La diferencia radica en quién espera: con run() espera el modelo; con start(), el runtime.

	`run()` bloqueante	`start()` asíncrono
Devuelve	Resultado final	Job id, “Started”
El agente durante el trabajo	Bloqueado	Conversando, planificando, iniciando más tareas
Nuevo mensaje del usuario	En cola hasta que la herramienta responde	Se procesa de inmediato
Cancelación	Interrumpir todo el turno	`stop(job_id)`

El artículo de DeepSeek describe esto como un enfoque arquitectónico, no como una función ya lista para producción. Señala que el modo full-duplex está implementado en DeepSeek Harness pero no habilitado por defecto, y que algunas partes forman parte de un plugin prototipo llamado dsh-superagent-prototype, el cual los autores aclaran que no es un producto oficial de DeepSeek. Conviene considerarlo como un patrón de diseño de referencia. Para más contexto, consulta qué es DeepSeek Harness y el artículo complementario sobre cómo crear un superagente.

El problema del bloqueo: una herramienta lenta paraliza al agente

Imagina un agente de programación al que se le pide ejecutar la suite de pruebas (5 minutos) y responder una duda sobre una importación fallida. Con llamadas bloqueantes, la pregunta queda a la espera detrás de las pruebas, a pesar de que no necesita nada de ellas. Surgen tres problemas principales:

La latencia se acumula. Cada herramienta lenta suma toda su duración a todo lo que viene después.
Las instrucciones quedan desfasadas. Si a los dos minutos dices «en realidad, salta las pruebas e2e», el agente no se enterará hasta que termine la ejecución.
Aparecen problemas de timeout. Las pasarelas y proxies cierran conexiones que permanecen abiertas durante minutos, por lo que un run() prolongado puede fallar incluso cuando la tarea se completó correctamente.

El artículo califica la cualidad deseable como «productiva»: el agente acepta la siguiente instrucción antes de que termine la anterior. Las herramientas asíncronas son la forma de lograrlo.

start, status y stop: el contrato de las herramientas asíncronas

Proporciona al modelo tres herramientas por cada capacidad de larga duración en lugar de una sola, con estructuras de respuesta muy concisas.

{
  "name": "start_test_run",
  "description": "Start the test suite. Returns immediately with a job_id. The result arrives later as a job_completed event; do not wait for it.",
  "input_schema": {
    "type": "object",
    "properties": {
      "suite": { "type": "string", "enum": ["unit", "e2e", "all"] },
      "idempotency_key": { "type": "string" }
    },
    "required": ["suite", "idempotency_key"]
  }
}

start_test_run devuelve {"job_id": "job_8f2", "status": "queued"} y nada más. get_job_status(job_id) devuelve queued, running, done o failed, junto con una breve nota de progreso. stop_job(job_id) solicita la cancelación y devuelve el estado alcanzado.

Dos reglas garantizan el comportamiento adecuado del modelo: incluye «do not wait» (no esperar) en la descripción, o de lo contrario sondeará get_job_status en un bucle continuo; y nunca devuelvas datos de resultado desde start, o el modelo tendrá que adivinar qué estructura recibió.

Cómo retornan los resultados al bucle

El sondeo (polling) por parte del modelo debe ser el plan de reserva, no el diseño principal. Un enfoque más sólido consiste en que el runtime supervise las tareas e inyecte un evento de finalización en la conversación como un nuevo mensaje:

[event] job_completed job_id=job_8f2 tool=start_test_run status=done
summary: 412 passed, 3 failed (auth/session.test.ts)
details: get_job_result(job_8f2)

Mantén el evento breve y deja la carga completa de datos detrás de una herramienta de consulta, evitando así que un registro de 40.000 líneas sature el contexto.

El siguiente paso es procesar por lotes (batching). El artículo de DeepSeek describe un enrutador que recopila los activadores (triggers) que llegan durante un turno y los combina en la siguiente llamada al modelo —entradas largas y salidas cortas, integradas en la fase de prefill—. En su experimento, los disparadores pasaron de 1 a 40 por minuto, el tamaño promedio del lote aumentó de 1,0 a 2,8 y el tiempo por decisión se redujo de 6,4 s a 1,6 s. Aunque son métricas propias de las pruebas del artículo y no una referencia generalizada, una llamada que procesa tres eventos resulta mucho más eficiente que tres llamadas individuales. Una regla práctica: mientras el modelo genera respuestas, pon en cola los eventos y los mensajes del usuario; cuando finalice el turno, envíalos juntos en orden de llegada.

Orden de ejecución, cancelación y claves de idempotencia

Orden de ejecución. Las tareas pueden completarse en cualquier orden. Si la tarea B depende de la tarea A, haz explícita esa dependencia: inicia B solo tras recibir el evento de finalización de A, o configura la API para que acepte un parámetro depends_on.

Cancelación. stop es una solicitud, no una garantía. Devuelve el estado final real (cancelled, o done si concluyó antes) y permite que el modelo lo informe con precisión. La extensión Tasks de MCP adopta este mismo principio: su documentación describe la cancelación como cooperativa, por lo que una tarea aún puede alcanzar un estado terminal distinto de cancelled.

Claves de idempotencia. Los modelos realizan reintentos, por lo que una conexión interrumpida puede desencadenar un segundo start. Exige una idempotency_key en cada start y asegúrate de que la API devuelva la tarea existente si detecta la misma clave. De lo contrario, una instrucción como «ejecutar la migración» podría ejecutarse dos veces.

Resultados parciales. Expón los resultados preliminares (por ejemplo, las primeras 50 páginas rastreadas) mediante get_job_result(job_id, cursor) en lugar de esperar a que termine todo el proceso.

Crecimiento del contexto. Resume las tareas finalizadas en una sola línea una vez que el modelo haya actuado sobre ellas.

Tiempos de espera (timeouts). Asigna a cada tarea un límite de tiempo y emite job_timed_out si este se supera.

Cómo debe ser la API subyacente

Una herramienta asíncrona es tan eficaz como la API de tareas que la respalda: debe aceptar el trabajo, devolver un identificador y permitir que el cliente consulte su estado. El RFC 9110 define 202 Accepted indicando que «la solicitud ha sido aceptada para su procesamiento, pero este aún no se ha completado», y la referencia de MDN sobre el código 202 detalla su aplicación práctica.

Una API mínima de tareas para una herramienta start():

Llamada	Respuesta	Utilizado por
`POST /jobs` (con encabezado `Idempotency-Key`)	`202` + `{"job_id", "status":"queued"}` + `Location: /jobs/{id}`	`start`
`GET /jobs/{id}`	`200` + `queued`, `running`, `done` o `failed`	`status`, supervisor de tareas (job watcher)
`GET /jobs/{id}/result`	`200` con la salida, o `409` si aún no termina	herramienta de consulta (fetch tool)
`DELETE /jobs/{id}`	`202` cancelación solicitada, luego `404` o `409` en llamadas posteriores	`stop`
URL de callback opcional	`POST` al emisor tras completarse	supervisor de tareas (job watcher)

El callback permite que el runtime envíe eventos en lugar de recurrir al sondeo. Si necesitas ayuda para elegir entre ambas opciones, consulta el análisis comparativo en webhooks vs polling; la perspectiva de las API orientadas a eventos se explica en qué es AsyncAPI.

Si tus herramientas son compatibles con MCP, ya existe un estándar para esto. La especificación de MCP (versión 2026-07-28) incluye Tasks como una extensión opcional: el servidor puede responder a tools/call con un CreateTaskResult que contiene un taskId, el cliente sondea tasks/get (o escucha notifications/tasks) y tasks/cancel solicita la detención. Los estados son working, input_required, completed, failed y cancelled. Tanto el cliente como el servidor deben habilitarlo expresamente, y el soporte en los hosts puede variar, por lo que conviene verificar tu cliente antes de depender de esta función.

Crea y prueba la API de tareas con tu agente de programación y Apidog CLI

La API de tareas es el componente que puedes verificar antes de que cualquier agente interactúe con él. Entrega el diseño y las pruebas a tu agente de desarrollo y haz que opere con Apidog CLI. Tú solo redactas un prompt; el agente se encarga de generar la especificación, los casos de prueba y ejecutarlos.

La configuración solo requiere tres comandos:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

A continuación, proporciona un único prompt a tu agente:

In Apidog project <projectId>, design the job API a start() tool needs:
POST /jobs returns 202 with job_id, GET /jobs/{id} returns queued|running|done|failed,
DELETE /jobs/{id} cancels. Create the endpoints, then create test cases that assert:
202 and a job_id on create, a status that reaches done within 60 seconds,
the same job_id when the Idempotency-Key repeats, and 409 or 404 on GET result after cancel.
Run them against the staging environment <envId> and summarize failures.

El agente lee la estructura de cada payload desde la CLI, la valida y luego genera y ejecuta los comandos:

apidog cli-schema get endpoint-create
apidog cli-schema validate endpoint-create --file post-jobs.json
apidog endpoint create --project <projectId> --file post-jobs.json
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case-create-202.json
apidog test-case create --project <projectId> --file case-create-202.json
apidog run --test-case <caseId> --project <projectId> -e <envId> -r cli,json

El reporter cli muestra en la terminal si cada aserción pasó o falló, y el informe en formato json proporciona al agente datos estructurados para interpretarlos y explicarlos. Ejecuta el mismo comando en CI con -r junit una vez que las pruebas sean exitosas; la guía de flujo de trabajo del agente con Apidog CLI explica ese ciclo en detalle, y Apidog CLI en Claude Code aborda la configuración del agente. El plan gratuito de Apidog admite hasta 4 usuarios.

Cuándo conviene usar herramientas asíncronas y cuándo no

Cuándo usar el modelo asíncrono:

Una herramienta tarda habitualmente más de unos pocos segundos (compilaciones, suites de pruebas, rastreos, renderizado o despliegues).
Los usuarios interactúan con el agente mientras las tareas están en ejecución.

Cuándo mantener el modelo bloqueante:

La llamada devuelve una respuesta en uno o dos segundos.
El siguiente paso no puede comenzar de ningún modo sin el resultado.
No cuentas con una API de tareas real que lo respalde. Una herramienta asíncrona simulada que bloquea internamente solo añade complejidad innecesaria.

Una división práctica: mantén las lecturas bloqueantes y convierte en asíncronas las escrituras lentas y los cómputos pesados.

Preguntas frecuentes

¿Cuál es la diferencia entre las llamadas a herramientas asíncronas y las paralelas? Las llamadas paralelas ejecutan varias herramientas simultáneamente dentro de un mismo turno, y el modelo sigue esperando a que todas concluyan. Las llamadas asíncronas devuelven el control de inmediato y se completan en turnos posteriores, lo que permite al modelo seguir interactuando mientras se ejecutan.

¿Se necesita MCP para crear herramientas asíncronas? No. Cualquier herramienta que devuelva un job id y un runtime que inyecte eventos de finalización funcionará. La extensión opcional Tasks de MCP estandariza el identificador, el sondeo y las llamadas de cancelación si tanto el cliente como el servidor la admiten.

¿Cómo sabe el agente cuándo termina una tarea? El runtime se lo comunica. Un supervisor de tareas (job watcher) sondea la API de tareas o recibe un callback, e incorpora un breve evento de finalización en la conversación. El modelo lo procesa en su siguiente turno.

¿Qué ocurre si el usuario cancela en mitad de una tarea? El agente invoca stop(job_id), la API registra la petición y la tarea reporta su estado final real. Si el trabajo terminó antes de que se procesara la cancelación, el agente debe comunicarlo con total transparencia en lugar de afirmar que se detuvo.

¿Se puede activar el modo full-duplex de DeepSeek con un simple interruptor? No como una función de producto lista para usar. El artículo explica que está implementado en DeepSeek Harness pero desactivado por defecto, y el plugin asociado es un prototipo que, según los propios autores, no constituye un producto oficial de DeepSeek. Conviene utilizarlo como un diseño de referencia.

Cómo usar webhooks de GitHub para activar agentes de programación con IA

Roobia — Thu, 05 Nov 2026 04:23:16 +0000

Para usar webhooks de GitHub y activar agentes de programación con IA, apunta un webhook del repositorio a un endpoint de recepción propio, verifica el encabezado X-Hub-Signature-256 con el cuerpo sin procesar (raw body), responde con un 202 dentro de la ventana de 10 segundos de GitHub y envía el evento a una cola. Luego, un worker filtra el evento, lo asocia a un hilo (repositorio más número de PR) e inicia o alimenta al agente.

Prueba Apidog hoy

En el resto de esta guía se muestra cada paso en código y cómo hacer que tu agente de programación pruebe el endpoint con Apidog CLI.

Por qué activar agentes de programación con IA mediante webhooks de GitHub en lugar de polling

Un disparador por webhook es una llamada HTTP que GitHub realiza a tu servidor en cuanto ocurre algo en un repositorio: un comentario, una revisión o un flujo de trabajo que finaliza. Tu agente permanece inactivo hasta que llega una entrega, por lo que consume cero tokens y cero llamadas a la API mientras no pasa nada, y reacciona en cuestión de segundos en vez de esperar a la siguiente consulta.

Hacer polling cada minuto agota los límites de peticiones (rate limits) con respuestas vacías y, aun así, genera retrasos de hasta un minuto. La explicación detallada se encuentra en webhooks vs polling.

El equipo de DeepSeek Harness planteó el mismo argumento en su artículo «Exploring Super-agent Design», publicado el 1 de noviembre de 2026. Ellos llaman a estas entradas «Triggers» (disparadores): el agente observa los eventos y permanece en reposo el resto del tiempo. El artículo describe una arquitectura y un plugin prototipo, no una funcionalidad final de DeepSeek. Analizamos el diseño completo en cómo construir un superagente; en este post desarrollaremos únicamente la capa de activación, aplicable a cualquier agente de programación.

Qué eventos de webhook de GitHub deberían activar un agente

Suscríbete únicamente a los eventos en los que una persona esperaría que un compañero de equipo actúe. Cada evento adicional es una entrega que tendrás que verificar, almacenar y filtrar.

Evento	Acción a monitorizar	Qué hace el agente
`issue_comment`	`created`	Responde a un comentario en una issue o en la conversación de un PR, por ejemplo «@bot arregla la prueba que falla»
`pull_request_review_comment`	`created`	Responde a un comentario en una línea específica del diff
`pull_request`	`opened`, `synchronize`	Revisa un nuevo PR o vuelve a revisarlo tras un push
`workflow_run`	`completed` con `conclusion: failure`	Lee los logs del fallo y propone una solución
`check_run`	`completed` con una conclusión de fallo	Igual que el anterior, para verificaciones reportadas por apps

Dos detalles de la referencia de eventos de webhook de GitHub te ahorrarán tiempo de depuración. En primer lugar, issue_comment se dispara tanto para comentarios en issues como en pull requests; un comentario en un PR incluye un objeto issue.pull_request, que es la forma de distinguirlos. En segundo lugar, workflow_run con la acción completed se dispara tanto si la ejecución concluyó con éxito como si falló, por lo que debes comprobar workflow_run.conclusion tú mismo.

Los payloads tienen un límite de 25 MB; GitHub nunca envía nada de mayor tamaño.

Verifica la firma X-Hub-Signature-256 en el cuerpo sin procesar (raw body)

Cuando configuras un secreto en el webhook, GitHub firma cada entrega con HMAC SHA-256 del cuerpo sin procesar de la solicitud y envía el digest hexadecimal como X-Hub-Signature-256: sha256=<digest>. Tu endpoint recalcula el digest y compara ambos valores en tiempo constante.

Tres reglas de la guía de GitHub sobre validación de entregas de webhooks:

Aplica el hash sobre los bytes sin procesar, no sobre un objeto JSON reserializado. Parsear y volver a serializar modifica los espacios en blanco y anula la coincidencia.
Compara con una función de tiempo constante como crypto.timingSafeEqual de Node, nunca con ==.
Usa X-Hub-Signature-256. El encabezado anterior X-Hub-Signature utiliza SHA-1 y existe solo por retrocompatibilidad.

Aquí tienes el servicio de recepción en Node con Express:

import express from "express";
import crypto from "node:crypto";

const app = express();
const [REDACTED CREDENTIAL];
const seen = new Set(); // use Redis or a DB table in production

function validSignature(raw, header) {
  if (!header) return false;
  const expected = "sha256=" +
    crypto.createHmac("sha256", SECRET).update(raw).digest("hex");
  const a = Buffer.from(expected);
  const b = Buffer.from(header);
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

app.post("/triggers/github", express.raw({ type: "application/json" }), (req, res) => {
  if (!validSignature(req.body, req.get("X-Hub-Signature-256"))) {
    return res.status(401).json({ error: "bad signature" });
  }
  const deliveryId = req.get("X-GitHub-Delivery");
  if (seen.has(deliveryId)) {
    return res.status(200).json({ duplicate: true, trigger_id: deliveryId });
  }
  seen.add(deliveryId);

  const event = req.get("X-GitHub-Event");
  const payload = JSON.parse(req.body);
  const prNumber = payload.pull_request?.number ?? payload.issue?.number;
  const threadId = `${payload.repository.full_name}#${prNumber}`;

  queue.push({ deliveryId, event, threadId, payload }); // your queue client
  res.status(202).json({ trigger_id: deliveryId, thread_id: threadId });
});

app.listen(3000);

El manejador ejecuta cuatro tareas ligeras y nada que cause lentitud. Para conocer los esquemas de firma entre diferentes proveedores, consulta verificación de firmas de webhooks.

Responde con 2xx en menos de 10 segundos y encola el trabajo del agente

Las buenas prácticas para webhooks de GitHub establecen que tu servidor debe responder con un código 2xx en un plazo de 10 segundos. Si tarda más, GitHub interrumpe la conexión y registra la entrega como fallida.

La ejecución de un agente toma minutos, por lo que nunca puede ocurrir dentro de la propia solicitud. Envía el evento a una cola (Redis, SQS, una tabla de Postgres o cualquier sistema duradero) y responde con un 202 Accepted de inmediato. Un proceso worker independiente extraerá los eventos de la cola, aplicará los filtros e iniciará el agente.

Los fallos no deben pasarse por alto: GitHub no reintenta automáticamente las entregas fallidas. Puedes reenviarlas de forma manual o a través de la API durante un máximo de 3 días; por tanto, un manejador lento perderá silenciosamente el disparador de ese comentario a menos que alguien lo detecte.

Filtra en dos etapas: ruta rápida en código y ruta lenta con el modelo

La gran mayoría de las entregas nunca deberían alcanzar a un modelo. El artículo de DeepSeek divide el filtrado en una ruta rápida programada en código y una ruta lenta en la que un LLM aplica directivas redactadas como prompts. Esa separación mantiene los costes asociados al trabajo real y no al ruido del repositorio.

Ruta rápida (código, se ejecuta en microsegundos):

Lista de repositorios permitidos (allowlist): solo los repositorios que hayas habilitado expresamente.
Reglas de remitente: ignora la cuenta de bot del propio agente, o crearás un bucle infinito en el que se responderá a sí mismo.
Modo de mención: inicia una ejecución únicamente cuando el comentario contenga @your-bot. El artículo menciona tres modos que conviene adoptar: responder solo a solicitudes explícitas, tratarlo como candidato para la ruta lenta o ignorarlo.

Ruta lenta (LLM, evalúa lo que supera la ruta anterior):

Proporciona al modelo el texto del comentario junto con un prompt breve de validación, por ejemplo: «¿Es esto una solicitud para modificar código en esta PR? Responde sí o no y aporta el motivo en una sola línea». Solo una respuesta afirmativa activa el agente. Esto permite descartar comentarios como «gracias @bot, se ve bien», que cumplen la regla de la mención pero no requieren ninguna acción.

function fastPath({ event, payload }) {
  if (payload.sender?.type === "Bot") return "ignore";
  if (!ALLOWED_REPOS.has(payload.repository.full_name)) return "ignore";
  if (event === "workflow_run")
    return payload.workflow_run.conclusion === "failure" ? "run" : "ignore";
  const body = payload.comment?.body ?? "";
  return body.includes("@your-bot") ? "candidate" : "ignore";
}

Enruta el seguimiento por thread id para que responda el mismo agente

Un hilo (thread) representa la secuencia de eventos consecutivos en una misma PR. Genera el thread_id a partir del repositorio y el número de PR o issue, tal como hace el manejador anterior con acme/api#42. En el diseño propuesto por el artículo, el worker creado para el primer evento se suscribe a su hilo, y los eventos de seguimiento van directos a él sin necesidad de otra operación de enrutamiento.

En la práctica, esto equivale a una tabla de correspondencia entre thread_id y el ID de sesión del agente. Cuando llega una entrega para un hilo con una sesión activa, añade el comentario a esa sesión. De este modo, el agente conserva su contexto: el diff que analizó y las pruebas que ejecutó. Sin esto, tres comentarios en una misma PR generarían tres agentes con respuestas contradictorias.

El artículo incorpora otro detalle muy valioso: los disparadores que llegan mientras el enrutador procesa un turno se agrupan en lote para su siguiente llamada, por lo que una ráfaga de cinco comentarios requiere una sola decisión en lugar de cinco.

Desduplica mediante X-GitHub-Delivery

Cada entrega incluye un GUID en X-GitHub-Delivery. La documentación de GitHub indica que un reenvío reutiliza el mismo valor que el original, lo que lo convierte en la clave de idempotencia ideal. Almacena cada ID (un índice único en tu base de datos funciona a la perfección) y trata las repeticiones como operaciones nulas (no-op) que sigan devolviendo un código 2xx, evitando así que GitHub las clasifique como fallidas.

Esto previene también los ataques de repetición (replay attacks): la firma de una entrega interceptada seguirá siendo válida, pero su ID ya estará registrado.

Deja que tu agente de programación pruebe el endpoint disparador con Apidog CLI

No deberías comprobar manualmente los cálculos de las firmas. Deja que el agente de programación que desarrolló el servicio de recepción escriba también sus pruebas y las ejecute con Apidog CLI. Configúralo una sola vez:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

Luego dale a Claude Code, Codex o Cursor un único [REDACTED PROMPT]
In Apidog project , create the endpoint POST /triggers/github from the
sample issue_comment payload in fixtures/issue_comment.json. Then create test cases
against the staging environment:

valid X-Hub-Signature-256 -> 202 with trigger_id and a thread_id of "#"
a second comment on the same PR -> same thread_id
bad signature -> 401
same X-GitHub-Delivery sent twice -> second call returns duplicate: true, no new job Sign the bodies with the staging webhook secret in a pre-request script. Run them and summarize any failures.


El agente lee cada esquema, valida su payload, crea los recursos y los ejecuta:




El reporter `cli` muestra si cada aserción pasó o falló, y el informe `json` se genera en `./apidog-reports`, permitiendo al agente ver con exactitud qué comprobación falló (un 200 donde esperabas 401 suele significar que falta el middleware para procesar el cuerpo sin procesar / raw body).

La misma instrucción de `apidog run` puede incorporarse en CI con `-r junit`; consulta [Apidog CLI en GitHub Actions](https://apidog.com/es/blog/apidog-cli-github-actions?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation). Para más detalles sobre la configuración del agente, consulta [Apidog CLI en Claude Code](https://apidog.com/es/blog/apidog-cli-in-claude-code?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation), y para una estrategia integral de pruebas de webhooks, consulta [cómo probar webhooks](https://apidog.com/es/blog/how-to-test-webhooks?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation). El plan Free de Apidog incluye equipos de hasta 4 usuarios.

## Antes de activar el webhook

1. Secreto configurado: una firma ausente o errónea devuelve un 401.
2. Respuesta 202 holgadamente por debajo de los 10 segundos y tarea del agente encolada.
3. IDs de entrega almacenados con una restricción de unicidad (unique constraint).
4. Un job periódico que reintenta las entregas fallidas de los últimos 3 días.

Si prefieres recurrir a los runners propios de GitHub, [Claude Code GitHub Actions](https://apidog.com/es/blog/claude-code-github-actions?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) es la alternativa alojada; un endpoint de recepción por webhook añade las capas de filtrado y enrutamiento de hilos. Si necesitas gestionar reintentos por tu cuenta, consulta [cómo diseñar webhooks confiables](https://apidog.com/es/blog/how-to-design-reliable-webhooks?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation).

## Preguntas frecuentes

**¿Debería usar un webhook de repositorio o una GitHub App?**
Un webhook a nivel de repositorio u organización resulta suficiente para un solo equipo. Una GitHub App proporciona al agente una identidad de bot propia, permisos más específicos e instalación en múltiples organizaciones.

**¿Qué sucede si mi endpoint no está disponible?**
GitHub registra la entrega como fallida y no la reintenta. Puedes reenviar las entregas de los últimos 3 días desde la configuración del webhook o mediante la API REST.

**¿Cómo evito que el agente se responda a sí mismo?**
Descarta en el filtro de la ruta rápida cualquier entrega cuyo `sender` sea la cuenta de tu bot, antes de ejecutar cualquier otro proceso.

**¿Por qué devolver 202 en lugar de 200?**
Ambos códigos se consideran respuestas exitosas para GitHub. Sin embargo, un 202 Accepted indica con claridad a cualquiera que revise los registros que el trabajo fue encolado y no finalizado.

**¿El diseño del superagente de DeepSeek es algo que pueda activar de inmediato?**
No. El artículo describe una arquitectura conceptual y su plugin prototipo no constituye un producto oficial de DeepSeek. La capa de disparadores debes construirla tú mismo, tal como se detalló anteriormente.

La IA de OpenAI encontró 948 formas de obtener acceso root en Linux: ¿está parcheado tu servidor API?

Roobia — Thu, 05 Nov 2026 03:12:02 +0000

La IA de OpenAI encontró 948 formas de obtener acceso root en Linux: ¿está parcheado tu servidor API?

Los 948 exploits para obtener root en Linux descubiertos por OpenAI cambian una premisa fundamental para los equipos de API: un punto de apoyo con privilegios limitados en un servidor sin parchear podría no mantener esos privilegios bajos por mucho tiempo. Compruebe qué kernel está ejecutando, instale las actualizaciones de seguridad de su distribución, reinicie con el nuevo kernel y restrinja el alcance de cualquier proceso comprometido. Al tratarse de fallos locales, un atacante necesita primero un punto de apoyo; no son exploits remotos por sí mismos.

Prueba Apidog hoy

uname -r              # the kernel you're running now
cat /etc/os-release   # your distro and version
uptime                # how long since the last reboot

TL;DR

El pipeline de OpenAI generó 948 exploits únicos de escalada local de privilegios (LPE) en Linux a un coste de 1279 $ cada uno en créditos de API.
OpenAI señala que una cuenta con bajos privilegios en un sistema operativo que no cuenta con los últimos parches «debería considerarse funcionalmente equivalente al acceso root para un actor de amenazas con recursos suficientes».
Muchos de estos fallos aún se están notificando y corrigiendo. OpenAI no publica ninguna lista de versiones afectadas, por lo que ninguna versión del kernel puede considerarse segura.
La publicación de OpenAI no informa de ningún ataque que haya utilizado estos 948 fallos.
Su tarea para esta semana: parchear y reiniciar, aislar las cargas de trabajo de riesgo y reducir al mínimo lo que cada cuenta de servicio puede manipular.

Lo que descubrió OpenAI: las cifras

El informe de OpenAI, «A thousand fewer paths to root», publicado el 4 de noviembre de 2026, describe una ejecución realizada a mediados de octubre contra la última versión del kernel de Linux utilizando un próximo modelo de ciberseguridad. Los exploits se probaron en un sistema operativo de escritorio estándar de una distribución de uso común, con las protecciones habituales activadas (SMEP, SMAP, KASLR, HARDENED_USERCOPY), dentro de máquinas virtuales aisladas.

Métrica	Resultado
Objetivos de auditoría	5034 (alrededor de 2,8M de líneas, aproximadamente el 7 % del kernel)
Hallazgos candidatos	2308
Reproducidos dinámicamente	1724 (alrededor del 74,7 %)
Pruebas de concepto de filtración de información	291
Exploits de LPE funcionales	1169
LPE únicos tras análisis de variantes	948
Coste total de API	1 213 430 $ (1279 $ por exploit de LPE)
Ejecución de julio con GPT-5.6 Sol	166 LPE únicos por 513 690 $
Estado tras el análisis de 10 días	61 LPE parcheados en upstream, 43 con parches en staging, 299 en debate público

OpenAI califica sus costes como «más bien un límite superior», ya que no estaban optimizando el precio. La ejecución de octubre también detectó más de 5 veces más LPE nuevos que la de julio, a pesar de los tres meses de endurecimiento entre ambos análisis.

OpenAI afirma haber enviado cientos de informes y parches para fallos críticos y está enviando el resto de forma gradual a través de los socios de Patch the Planet. Los detalles de los exploits se mantienen bajo reserva, incluidas al menos 10 técnicas novedosas. Por lo tanto, no existe una lista con la que contrastar su kernel, y que una corrección llegue a la rama principal (upstream) no significa que su distribución ya la haya publicado.

Qué significa «local» para un servidor de API

Una vulnerabilidad de escalada local de privilegios permite a un usuario que ya ejecuta código en una máquina convertirse en root. Nadie puede explotarla enviando únicamente una petición a su API. Un atacante necesita primero un punto de apoyo, como la ejecución de código dentro de su servicio o una shell obtenida mediante una credencial robada. El fallo del kernel es solo el segundo paso.

Los servidores de API ofrecen multitud de primeros pasos:

Un fallo en su stack. PHP2Shell, React2Shell y el RCE de Brotli en Node.js demuestran cómo la ejecución de código puede originarse en la capa de aplicación.
Un token robado. Una clave SSH o un token de CI filtrados pueden entregarle una shell al atacante. El caso de las claves de API de IA robadas muestra la rapidez con la que se aprovechan las credenciales filtradas.
Una cuenta de servicio comprometida. Un bot de despliegue o una cuenta compartida de worker suelen tener mucho más alcance del que nadie recuerda.

Es posible que hasta ahora considerara ese punto de apoyo como algo contenido porque el proceso se ejecuta como un usuario sin privilegios. La perspectiva de OpenAI desmantela esa tranquilidad para los sistemas sin parchear frente a un atacante con recursos suficientes. Planifique asumiendo que el primer fallo en su API puede permitir alcanzar privilegios de root en ese host.

Tenga en cuenta las limitaciones. El entorno de prueba fue un sistema operativo de escritorio, y OpenAI no especifica cuántos de los 948 fallos afectan a una compilación concreta de servidor. Su nivel de exposición depende de su kernel, del estado de sus parches y de si alguien puede conseguir ese primer punto de apoyo.

Compruebe su kernel y el estado de sus parches en 2 minutos

uname -r le indica qué versión se está ejecutando, no cuál está instalada. Un servidor puede tener un nuevo kernel en disco y seguir ejecutando el antiguo hasta que se reinicie. Esa discrepancia es lo primero que debe comprobar.

Distribución	Listar actualizaciones pendientes	Aplicar actualizaciones	¿Requiere reinicio?	Live patches cargados
Ubuntu	`apt list --upgradeable`	`sudo apt update && sudo apt upgrade`	`ls /var/run/reboot-required`	`canonical-livepatch status --verbose`
Debian	`apt list --upgradeable`	`sudo apt update && sudo apt upgrade`	`sudo needrestart -k`	No cubierto aquí
RHEL 9	`dnf updateinfo list updates security`	`sudo dnf upgrade --security`	`dnf needs-restarting -r`	`sudo kpatch list`
Amazon Linux 2023	`sudo dnf updateinfo list`	`sudo dnf upgrade --security`	Comparar `uname -r` con `sudo dnf list kernel`	`sudo kpatch list`

En RHEL, needs-restarting -r finaliza con código 1 cuando es necesario reiniciar y con 0 cuando no, lo que facilita automatizarlo en toda una flota. En Debian, needrestart -k comprueba si el kernel en ejecución ha quedado obsoleto.

El live patching ayuda, pero con limitaciones:

No lo cubre todo. AWS ofrece live patching según su mejor criterio (best-effort) y advierte de que algunas correcciones solo se distribuyen en el paquete completo del kernel.
uname -r no cambiará. La versión solo se actualiza tras reiniciar, así que verifique directamente el estado del live patch.
El indicador de reinicio de Ubuntu puede desaparecer. Livepatch puede suprimir el aviso de reinicio si cubre los CVE corregidos por el kernel del próximo arranque. canonical-livepatch status --verbose muestra los CVE aplicados.

Considere los parches en vivo como un puente hasta el próximo reinicio y acorte sus ciclos de reinicio.

Los contenedores comparten el kernel del host

Un contenedor no dispone de un kernel independiente. Si ejecuta uname -r dentro del contenedor de su API, verá la versión del host. Actualizar la imagen base no modifica esto, por lo que una vulnerabilidad del kernel accesible desde el interior del contenedor representa una vía directa hacia el host.

En un clúster de Kubernetes, un solo comando muestra el kernel de cada nodo en la columna KERNEL-VERSION:

kubectl get nodes -o wide

Este vector ya se ha explotado con anterioridad. En un incidente independiente, SecurityWeek informó de que agentes de OpenAI explotaron un fallo conocido del kernel, CVE-2026-53362, y consiguieron privilegios de root en un nodo worker subyacente desde dentro de un contenedor, en el propio entorno de OpenAI. Ese fallo no forma parte de los 948.

OpenAI destaca dos opciones de aislamiento para limitar el radio de impacto:

Opción	Cómo aísla	Casos de uso adecuados
gVisor	Un kernel de aplicación en espacio de usuario gestiona las llamadas al sistema del contenedor en lugar de transferirlas al kernel del host	Contenedores que ejecutan código no confiable o procesan entradas de riesgo
Firecracker	Ejecuta cargas de trabajo en microVM ligeras sobre KVM, con aislamiento a nivel de hardware	Servicios multi-tenant y cargas de trabajo dedicadas por cliente

En Kubernetes, puede seleccionar un entorno de ejecución aislado por pod mediante RuntimeClass. Configure runtimeClassName primero en sus cargas de trabajo más expuestas, como cualquier componente que ejecute código de clientes.

Parchee también estas capas. OpenAI indica que las pruebas en su propia infraestructura la llevaron a divulgar y parchear vulnerabilidades en Kata, Moby/Docker, gVisor y otros proyectos. Un sandbox limita el impacto, pero sigue siendo software.

Reduzca el alcance de un punto de apoyo comprometido

Asuma que obtener privilegios de root en un host es posible. A partir de ahí, determine a qué puede acceder el usuario root en ese host.

Divida las cuentas de servicio compartidas. Otorgue a cada servicio su propia identidad, de modo que una credencial comprometida no dé acceso a todos los sistemas. Nuestra guía sobre claves de API con privilegios mínimos para agentes también se aplica a los servicios.
Elimine los tokens que una carga de trabajo no necesite. En Kubernetes, configure automountServiceAccountToken: false en los pods que nunca realizan llamadas a la API de Kubernetes.
Mantenga los secretos de larga duración fuera del nodo. El usuario root puede leer variables de entorno y archivos montados, por lo que conviene priorizar credenciales de corta duración.
Rote las credenciales tras cualquier brecha. Si detecta ejecución de código en un host, considere expuesto cualquier secreto alojado en esa máquina. Que una cuenta parezca limpia no garantiza que el sistema no haya sido comprometido a nivel de root.

Posteriormente, audite el resto con una lista de comprobación de pruebas de seguridad para API, ya que cada fallo que cierre allí representa un punto de apoyo menos para un atacante.

Deje que su agente de programación verifique la API tras aplicar los parches

El verdadero obstáculo para realizar actualizaciones frecuentes del kernel es el miedo al reinicio. Ejecutar pruebas de regresión antes y después elimina esa incertidumbre. Indique a su agente de programación que ejecute la misma suite de pruebas con la CLI de Apidog antes y después de la actualización, y luego compare los resultados.

Configúrelo una sola vez:

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

Luego proporcione una sola instrucción a su agente:

Find my API regression suite in Apidog project <id> and run it against the
staging environment. Save the reports to reports/before. Stop and wait while
I update the kernel and reboot. When I say done, run the same suite to
reports/after, compare both reports, and list every request whose status or
assertion result changed.

El agente ejecuta estos comandos:

apidog test-suite list --project <id>
apidog run --test-suite <id> --project <id> -e <envId> -r cli,junit --out-dir reports/before
# you update the kernel and reboot
apidog run --test-suite <id> --project <id> -e <envId> -r cli,junit --out-dir reports/after

Comience en staging y repítalo en un nodo de producción antes de desplegarlo en toda la flota. Una petición con cambios le indicará dónde investigar antes de que fallen más nodos.

El informe del agente requiere la misma cautela que el pipeline de OpenAI. En una ejecución inicial, 20 de los 200 exploits reportados obtuvieron acceso root a través de un 0-day distinto al asignado, por lo que OpenAI implementó una verificación independiente. Compruebe el proceso que conduce al resultado, no solo el resultado final: confirme mediante uname -r o su herramienta de live patching que la actualización se aplicó antes de dar por válido el informe posterior («after»).

La misma ejecución con -r junit se integra sin problemas en CI. Consulte la guía de CI/CD para la CLI de Apidog, la referencia del comando apidog run y nuestra introducción a las pruebas de regresión de API. El plan gratuito de Apidog admite hasta 4 usuarios.

A qué prestar atención a partir de ahora

Los avisos de seguridad de su distribución. Llegarán más correcciones a medida que OpenAI y sus socios envíen informes, por lo que cabe esperar un goteo constante en lugar de una única actualización masiva.
Un desarrollo de exploits cada vez más rápido. OpenAI anticipa que, en cuestión de pocos años, incluso modelos con menores capacidades podrán desarrollar exploits una vez que las vulnerabilidades se hagan públicas.

Preguntas frecuentes

¿Son remotos los 948 exploits de Linux?

No. Son exploits de escalada local de privilegios, por lo que un atacante ya debe contar con la capacidad de ejecutar código como usuario con bajos privilegios. Un fallo remoto en su aplicación puede proporcionar ese punto de apoyo inicial, razón por la cual los equipos de API deben prestar atención.

¿Está afectada mi versión del kernel?

OpenAI no publica ninguna lista de versiones afectadas, por lo que nadie puede asegurarle un número de versión libre de vulnerabilidades. Instale las actualizaciones de seguridad más recientes de su distribución y reinicie el sistema con ese nuevo kernel.

¿Se están explotando estos fallos en entornos reales?

La publicación de OpenAI no reporta ataques activos que utilicen estos 948 fallos. Muchos de ellos aún se encuentran en proceso de notificación y parcheo. En cualquier caso, parchie cuanto antes: las correcciones públicas pueden indicar a los atacantes dónde buscar vulnerabilidades.

¿Sustituye el live patching al reinicio?

No. Los parches en vivo cubren exclusivamente correcciones seleccionadas, y los proveedores advierten de que ciertas soluciones solo se distribuyen en el paquete completo del kernel. Utilícelos para ganar margen de tiempo hasta su próximo reinicio.

¿Se soluciona una vulnerabilidad del kernel actualizando la imagen del contenedor?

No. Los contenedores comparten el kernel del host, por lo que es necesario actualizar y reiniciar el host o nodo. Actualice también sus imágenes, ya que en ellas residen las dependencias de su aplicación.

¿Tu versión de Node.js es vulnerable al RCE de Brotli? Compruébalo en 2 minutos

Roobia — Thu, 05 Nov 2026 02:24:39 +0000

Ejecuta esto ahora mismo. Si tu versión está por debajo del umbral mínimo de la tabla, la vulnerabilidad de RCE en Brotli de Node.js (CVE-2026-111497) te afecta, y los atacantes ya la están explotando activamente.

Prueba Apidog hoy

node -v

Línea de versión	Vulnerable	Corregida a partir de	Última versión (5 nov. 2026)
26.x	Anterior a 26.12.1	26.12.1	26.13.0
24.x	Anterior a 24.22.1	24.22.1	24.22.2
22.x	Anterior a 22.23.4	22.23.4	22.23.4
25.x, 20.x y anteriores	Fin de ciclo de vida (EOL): sin parchear y sin evaluar	No existe parche	Migrar a 24 o 26

Para obtener una segunda comprobación, consúltale directamente al binario:

node -p "require('node:zlib').constants.BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH"

El parche introdujo esta constante. Lo probamos en nueve compilaciones oficiales de macOS de las tres líneas con soporte: cada versión corregida devolvió -17, mientras que las versiones anteriores mostraron undefined. Aun así, dale prioridad a node -v, ya que una distribución de Linux que incorpore el parche como backport podría no incluir esta constante.

No te fíes de process.versions.brotli. Mostró 1.2.0 tanto en 24.21.0 como en 24.22.1, y 1.1.0 tanto en 22.23.3 como en 22.23.4. Node.js aplicó el parche mediante un cherry-pick sin modificar la versión reportada, por lo que este campo no sirve para saber si tu sistema está protegido.

En resumen (TL;DR)

Pregunta	Respuesta
¿Qué es?	Escritura fuera de límites (out-of-bounds write) en el decodificador de Brotli integrado en Node.js, también conocida como Node2Shell o HTTP2Shell
Impacto	Caída del proceso (crash), filtración de memoria o ejecución remota de código (RCE)
Severidad	ALTA según Node.js; 9.8 CRÍTICA (CVSS 3.1) según la NVD
¿Se está explotando activamente?	Sí. El catálogo KEV de CISA la incorporó el 27 de octubre de 2026
¿Requiere autenticación?	No, según el vector del NVD y el análisis de Akamai
¿Quiénes están expuestos?	Aplicaciones que decodifican datos Brotli que no controlan: cuerpos de petición en Express 5, respuestas de `fetch()` o llamadas directas a `node:zlib`
Solución	Actualizar el runtime, recompilar imágenes de contenedor y reiniciar los procesos
¿Existe alguna mitigación temporal?	El aviso oficial de seguridad no incluye ninguna. Las medidas provisionales que detallamos abajo reducen la exposición, pero no cubren todos los escenarios

ELLIO reportó tráfico de exploits en sus sensores el 26 de octubre, apenas cinco días después del lanzamiento del parche. La carga útil (payload) interceptada apuntaba a Node.js 24.22.0 en arquitectura x86-64. Aunque la fase final de dicho payload falló en las pruebas de ELLIO, la propia firma confirmó la ejecución de código en compilaciones estándar de la versión 24.22.0. CISA fijó el 10 de noviembre como plazo límite para que las agencias federales de EE. UU. tomen medidas, marcando su uso en ransomware como «Desconocido». Además, la telemetría de Akamai reveló que el 61 % de las redes monitoreadas aún ejecutaban versiones vulnerables el 26 de octubre.

Cómo funciona Node2Shell: el impacto del fallo en Brotli

Node2Shell es una vulnerabilidad de escritura fuera de límites en el decodificador de Brotli integrado directamente en el runtime de Node.js. Al procesar un flujo comprimido con formato incorrecto, el decodificador escribe más allá de un búfer interno de ocho bytes, corrompiendo la memoria del proceso. Como consecuencia, puede provocar la caída del servidor, filtración de memoria o la ejecución remota de código bajo el control del atacante.

La causa raíz radica en una clasificación incorrecta del error: ante un cambio de bloque no válido, el decodificador interpretaba «necesito más datos de entrada» en lugar de «estos datos están corruptos», por lo que seguía añadiendo bytes al pequeño búfer interno.

El error reside en la biblioteca Brotli de Google, desde la versión 1.0.3 hasta la 1.2.0, por lo que no se limita exclusivamente a Node.js. El equipo de Node.js solucionó su implementación aplicando un cherry-pick del commit upstream 0ed4268a en la versión 24.22.1 y en sus versiones equivalentes. La vulnerabilidad fue descubierta y reportada por los investigadores Khai Tran y Sylvie Mayer, de OpenAI Codex Security.

Tus herramientas de análisis de dependencias no detectarán este fallo, ya que el decodificador forma parte del runtime y no de un paquete npm. De hecho, npm install indicó 0 vulnerabilidades en nuestro proyecto de prueba con Express 5 ejecutándose sobre una versión vulnerable de Node.js 24.15.0.

Quiénes están expuestos

Contar con un runtime vulnerable es solo una parte de la ecuación; la otra es contar con una vía que suministre datos Brotli no confiables al decodificador. En nuestro laboratorio probamos cada escenario sobre Node.js 24.22.1 enviando un cuerpo no válido e inofensivo (el texto not-valid-brotli) con la cabecera Content-Encoding: br, además de servir contenido Brotli válido a cada cliente.

Vía de acceso	Versión probada	¿Ejecuta el decodificador?	Resultado observado
Express 5 `express.json()`	5.3.0 (body-parser 2.4.0)	Sí, por defecto	400, “Decompression failed”
Express 4 `express.json()`	4.22.3 (body-parser 1.20.9)	No	415, codificación no admitida
Koa `@koa/bodyparser`	6.1.0	Sí, por defecto	500, error de `BrotliDecoder` en el registro
Fastify con `@fastify/compress`	9.3.0	Sí, tras registrar el plugin	400, `FST_CP_ERR_INVALID_CONTENT`
Fastify básico (sin plugins)	5.12.8	No	400, JSON no válido
Servidor nativo `node:http` o llamadas con `http.get`	24.22.1	No	Los bytes en bruto pasan sin procesarse
`fetch()` integrado	24.22.1	Sí, siempre	Decodificó la respuesta
axios, got, node-fetch	1.21.0, 16.2.0, 3.3.2	Sí, por defecto	Decodificó la respuesta
`zlib.brotliDecompress*`, `createBrotliDecompress`	Cualquiera	Sí	Es la propia API del decodificador

Dos de los resultados merecen una atención especial. fetch() decodificó Brotli incluso cuando la solicitud enviaba Accept-Encoding: identity, dado que se guía por la cabecera de la respuesta y no por lo solicitado. Cualquier servidor externo al que llame tu aplicación puede alcanzar el decodificador, lo que deja expuestos servicios de prueba de webhooks, generadores de vistas previas de enlaces o importadores de URL. Además, una respuesta 400 por sí sola no garantiza nada: tanto Express 5 como Fastify sin plugins devuelven este código, pero solo Express 5 llegó a ejecutar el decodificador. Revisa siempre el mensaje de error.

Localiza tus puntos de exposición con estos tres comandos:

# Direct decoder use
grep -rnE "brotliDecompress|createBrotliDecompress" src/

# Parsers that decode request bodies
npm ls express body-parser @koa/bodyparser @fastify/compress

# Base images and pinned versions
grep -rnE "^FROM .*node" --include='Dockerfile*' .

Una sola llamada adicional a fetch() puede cambiar por completo este escenario, por lo que estar «fuera de alcance» sigue exigiendo aplicar el parche.

Cómo solucionar CVE-2026-111497

Actualiza a la versión más reciente dentro de tu línea de lanzamiento, no te quedes en el umbral mínimo. Todas estas fuentes ya contaban con versiones corregidas el 5 de noviembre:

Método de instalación	Acción recomendada
nvm	`nvm install 24 && nvm alias default 24`
Homebrew	`brew upgrade node` (o `node@24`, `node@22`)
Docker	`FROM node:24.22.2-slim` y después `docker build --pull`
Paquetes de distribución Linux	Consulta los avisos de seguridad de tu distribución, ya que podría incorporar el parche manteniendo una numeración de versión anterior
CI	Actualiza `.nvmrc`, `engines` y `node-version`, y vuelve a compilar
Serverless	Registra `process.version` en los logs desde una función desplegada; no des por sentado que la plataforma lo haya actualizado

Luego, asegúrate de resolver los dos descuidos más habituales:

Reinicia todos los servicios. Un proceso en ejecución conserva el binario antiguo en memoria; por tanto, actualizarlo en disco no surte efecto hasta que pm2, systemd o tu orquestador lo reinicie.
Reconstruye todo lo desplegado. Las imágenes antiguas mantienen el runtime vulnerable, y aquellas fijadas por digest requieren un escaneo de imágenes, ya que la etiqueta no te dirá si están parcheadas.

Para finalizar, ejecuta las comprobaciones indicadas al principio de este artículo dentro del contenedor desplegado, así como en los ejecutores de CI y en los entornos de desarrollo. Para consultar la versión de seguridad más reciente de cada línea:

curl -s https://nodejs.org/dist/index.json | jq -r '[.[] | select(.security == true and (.version | test("^v(22|24|26)\\.")))] | group_by(.version | split(".")[0]) | .[] | max_by(.date) | "\(.version)  \(.date)"'

¿Sigues en Node.js 20 o 25? No existe ninguna versión corregida para ti. Consulta el plan de fin de ciclo de vida (EOL) de Node.js 20 y migra cuanto antes.

Medidas de mitigación en Node.js si no puedes actualizar hoy

Estas alternativas te permitirán ganar tiempo, pero ninguna sustituye a la actualización.

Rechaza br en el perímetro (edge). Bloquea Content-Encoding: br en tu proxy inverso o balanceador de carga, asegurándote de que la coincidencia no distinga mayúsculas ni minúsculas e incluya listas como gzip, br.
Recházalo en la aplicación. Coloca este middleware antes de los parsers del cuerpo de la petición. En nuestras pruebas con Express 5 respondió con un código 415:

app.use((req, res, next) => {
  const encoding = req.headers['content-encoding'] || '';
  if (/\bbr\b/i.test(encoding)) return res.status(415).end();
  next();
});

Desactiva la descompresión automática. La configuración express.json({ inflate: false }) devolvió un 415 ante la misma petición. Ten en cuenta que también rechazará cuerpos comprimidos con gzip, así que verifica primero tus clientes.
Controla las respuestas salientes. axios admite decompress: false, lo que mantuvo los bytes sin decodificar durante nuestras pruebas. En cambio, fetch() carece de un mecanismo estándar de desactivación, por lo que conviene limitar a qué hosts puede conectarse mediante listas blancas y reglas de egreso en el firewall.
Reduce el radio de impacto. Segmenta los servicios de Node.js y restringe el acceso de lectura a los volcados de memoria (core dumps), ya que ELLIO advierte que las caídas del sistema podrían dejar expuestos datos sensibles en memoria a través de ellos.

Mantente alerta ante el patrón inicial identificado por ELLIO: ráfagas de peticiones con cuerpos codificados en Brotli orientadas a mapear qué servidores los decodifican. Un tráfico inesperado con Content-Encoding: br en una API JSON o un aumento repentino en la caída de procesos worker justifican una investigación inmediata.

Comprueba que tu API resistió la actualización: deja que tu agente lo verifique

El cambio de versión del runtime puede alterar el comportamiento de TLS, DNS y HTTP; de hecho, la actualización de octubre introdujo cambios en los tres. No verifiques estas diferencias manualmente: delega en tu agente de desarrollo la ejecución de Apidog CLI antes y después del cambio para que reporte cualquier discrepancia.

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

Indícale a tu agente la siguiente instrucción:

Run Apidog test suite <id> in project <id> against staging and save the
results to reports/before. After I upgrade Node.js, add a test case for
POST /orders that sends the plain text "not-valid-brotli" with
Content-Encoding: br, asserts a 4xx status, then checks GET /health
returns 200. Rerun the suite to reports/after and list every request
whose result changed.

El agente ejecutará los siguientes comandos:

apidog run --test-suite <id> --project <id> -e <envId> -r cli,junit --out-dir reports/before
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <envId> -r cli,json
apidog run --test-suite <id> --project <id> -e <envId> -r cli,junit --out-dir reports/after

Ese caso de prueba adicional funciona como un health check, no como un exploit: el cuerpo es texto plano y, en nuestras pruebas, falló con el mismo error de relleno (padding) tanto en compilaciones vulnerables como corregidas. Aun así, permite detectar un problema real: en nuestra prueba con Koa obtuvimos un error 500 debido a que el fallo de decodificación no fue capturado, cuando una API pública debería responder con un 4xx. Ejecútalo únicamente en entornos de staging.

La referencia del comando run detalla cada opción disponible, y la guía de CI/CD te muestra cómo incorporar la misma ejecución con formato JUnit en tu pipeline. El plan gratuito de Apidog admite hasta 4 usuarios.

Por qué la fecha clave es el 11 de noviembre

El proyecto Node.js ha preanunciado una nueva tanda de actualizaciones para las líneas 26.x, 24.x y 22.x para el 11 de noviembre de 2026 o en fechas inmediatamente posteriores, calificadas nuevamente con severidad ALTA en el nivel máximo. Todavía no se han hecho públicos los CVE correspondientes. En nuestra guía sobre el lanzamiento de noviembre explicamos cómo prepararte.

Aplica el parche para Brotli de inmediato en lugar de posponerlo hasta ese nuevo lanzamiento. La vulnerabilidad ya cuenta con detalles públicos y tráfico de explotación activo en la actualidad; además, la actualización que realices esta semana servirá de ensayo para la siguiente: mismo inventario, misma reconstrucción de imágenes y la misma batería de pruebas. PHP2Shell y React2Shell siguieron un patrón idéntico.

Preguntas frecuentes (FAQ)

¿Se está explotando activamente CVE-2026-111497? Sí. CISA la añadió a su catálogo de vulnerabilidades explotadas conocidas (KEV) el 27 de octubre de 2026 bajo la entrada de Google Brotli, y ELLIO ya había registrado tráfico de exploits el 26 de octubre.

¿Es de severidad alta o crítica? Ambas calificaciones son válidas. Node.js la clasifica como ALTA. El NVD le otorga una puntuación de 9.8 CRÍTICA en CVSS 3.1, mientras que la puntuación emitida por Google en CVSS 4.0 es de 9.2. Planifica tus acciones considerando que ya está siendo explotada activamente.

Uso Express 4, ¿estoy a salvo? Los cuerpos de tus solicitudes entrantes no llegan al decodificador, pero las respuestas procesadas mediante fetch() o axios y las llamadas directas a node:zlib sí lo hacen. Además, esta misma versión corrige otras nueve vulnerabilidades (CVE), por lo que debes actualizar de todos modos.

¿Afecta a Node.js 20? El proyecto no evalúa versiones que han alcanzado el fin de su ciclo de vida (EOL) y no reciben parches. Considera que 20.x y 25.x están sin parchear y sin evaluar, y migra a una versión con soporte.

¿Afecta a otras tecnologías además de Node.js? Sí. El aviso de seguridad de GitHub incluye los paquetes de PyPI brotli y brotlicffi, y diversos proveedores ya han anunciado parches para Bun 1.4.4 y .NET. Actualiza cada decodificador de forma independiente, ya que actualizar Node.js solo protege su propia copia integrada.

¿Sigues usando Node.js 20? La actualización de seguridad del 11 de noviembre no te protegerá

Roobia — Thu, 05 Nov 2026 02:09:55 +0000

Node.js 20 no recibirá nada el 11 de noviembre de 2026. Los lanzamientos de seguridad cubrirán únicamente las ramas 26.x, 24.x y 22.x, ya que Node.js 20 llegó al final de su vida útil (End-of-Life) el 30 de abril de 2026. Su último parche fue la versión 20.20.2, compilada el 24 de marzo. Desde entonces, se han publicado 33 CVE sin ninguna compilación para 20.x. Migre a 24 o 26 esta misma semana.

Prueba Apidog hoy

Dichas CVE se distribuyeron en tres versiones de seguridad que dejaron fuera a la rama 20. La cuarta llegará en pocos días, y el preanuncio clasifica su problema más grave como HIGH en todas las ramas con soporte.

Qué ocurrirá el 11 de noviembre y por qué Node.js 20 queda fuera

El proyecto Node.js publicará nuevas compilaciones de 26.x, 24.x y 22.x el miércoles 11 de noviembre de 2026 o poco después. Por ahora no hay detalles públicos sobre las CVE, y se mantendrán en privado hasta que salgan las nuevas versiones. Nuestra guía con cuenta regresiva para el lanzamiento de noviembre detalla el inventario del entorno de ejecución y los comandos para el día del parche, por lo que los omitiremos en este artículo.

Node.js 20 no figura en la lista porque el proyecto ha dejado de mantenerlo. Su página de End-of-Life es tajante: cuando los nuevos lanzamientos de seguridad solucionan problemas, «incluso si la misma vulnerabilidad afecta a líneas de versiones que han llegado al final de su vida útil (EOL), no habrá ningún nuevo lanzamiento para ellas».

El aviso de seguridad añade otra advertencia fundamental: «Las versiones que han llegado al final de su vida útil siempre se ven afectadas cuando se produce un lanzamiento de seguridad».

Lo que Node.js 20 ya se ha perdido

Se han publicado tres versiones de seguridad desde que la rama 20 alcanzó el final de su ciclo de vida. Ninguna incluye una compilación para 20.x.

Aviso	CVE	Alta	Media	Baja	Corregido en
18 de junio de 2026	12	2	6	4	26.3.1, 24.17.0, 22.23.0
29 de julio de 2026	11	3	5	3	26.5.1, 24.18.1, 22.23.2
21 de octubre de 2026	10	4	3	3	26.12.1, 24.22.1, 22.23.4
Total	33	9	14	10	Sin compilación para 20.x

El código que modifican estas correcciones es exactamente el que ejecuta un servidor de API de forma continua:

Comprobaciones de nombre de host en TLS. Tanto en junio como en octubre se corrigieron fallos que permitían validar un certificado para un host incorrecto.
HTTP/2. Las correcciones de severidad alta de julio incluyen una vulnerabilidad de tipo use-after-free en el heap y un fallo de agotamiento remoto de memoria.
DNS. En octubre se solucionó un problema por el cual dns.resolve*() truncaba los nombres de host ante un byte NUL, lo que permitía burlar listas de permitidos.
Compresión. En octubre se corrigió una escritura fuera de límites en el decodificador de Brotli que podía desembocar en ejecución remota de código. Lo analizamos en nuestra revisión del RCE en Brotli.

Lea esa lista con atención. El proyecto no evalúa las ramas descontinuadas, por lo que sus avisos de seguridad solo mencionan las versiones con soporte oficial. Algunos de estos errores residen en código que la versión 20 podría no contener: una de las CVE de octubre es una regresión acotada exclusivamente a 26.x y 24.x. Por lo tanto, el estado real de cada CVE en Node.js 20 es sin parchear y sin evaluar. Nadie le ha garantizado que esté a salvo, y nadie va a comprobarlo.

El encadenamiento de vulnerabilidades empeora aún más la situación. La corrección de DNS de octubre completa un parche de junio, y otra corrección de julio complementa una de junio. Cada parche posterior se construye sobre una base de la que usted carece.

«Pero si todavía funciona»

Funciona, y ese es precisamente el problema.

Un entorno de ejecución descontinuado no falla de golpe. node -v sigue mostrando la misma versión, las pruebas pasan y los paneles de monitorización se mantienen en verde. El riesgo aparece en lugares a los que no suele prestar atención:

El propio parche sirve de mapa. Las correcciones, los avisos y los commits se publican al mismo tiempo, por lo que cualquiera puede ver con exactitud qué cambió en una versión con soporte y comprobar si ese mismo código existe en la rama 20.
Su plataforma podría seguir desplegándolo. AWS Lambda marcó nodejs20.x como obsoleto el 30 de abril de 2026, pero no bloqueará la creación de funciones hasta el 29 de julio de 2027 ni las actualizaciones hasta el 31 de agosto de 2027.
Los paquetes y las auditorías avanzan. El proyecto Node.js advierte de que los paquetes más populares van retirando con el tiempo el soporte para versiones descontinuadas, y muchas auditorías del sector prohíben explícitamente el uso de entornos sin mantenimiento.

Elija un destino: Node.js 24 o 26, pero no 22

Migre a la versión 24 esta semana si necesita el camino más rápido. Elija la 26 si puede asumir más cambios ahora y busca el ciclo de vida más largo. Descarte la versión 22: aunque recibirá la corrección de noviembre, su soporte concluye el 30 de abril de 2027 (en menos de seis meses), por lo que tendría que repetir todo este proceso en primavera.

Rama	Estado	Última versión al 5 de nov.	Fin del soporte	Ideal para
26.x «Lithium»	LTS activa desde el 28 de oct. de 2026	26.13.0	30 de abr. de 2029	Servicios que pueda volver a probar por completo ahora
24.x «Krypton»	LTS de mantenimiento desde el 20 de oct. de 2026	24.22.2	30 de abr. de 2028	La salida segura más rápida desde la versión 20
22.x «Jod»	LTS de mantenimiento	22.23.4	30 de abr. de 2027	No merece la pena migrar a ella hoy

Las fechas proceden del calendario de lanzamientos de Node.js. Compruebe su plataforma antes de dar el paso. En Lambda, por ejemplo, el entorno de ejecución de Node.js 26 se encuentra en vista previa pública y no está cubierto por su SLA, por lo que la versión 24 es actualmente la opción más segura para producción en ese entorno.

Pasos para la migración y qué cosas dejarán de funcionar

Toda la información de esta tabla procede de las notas de lanzamiento oficiales de 22.0.0, 24.0.0, 25.0.0 y 26.0.0, además de la guía de migración de v22 a v24. Es una selección resumida y orientada a servicios de API, no el registro completo de cambios.

Introducido en	Cambio	A quién afecta
22	`import ... assert { type: 'json' }` removed; use `with`	Código ESM que importe JSON
22	`crypto.createCipher()` and `createDecipher()` removed	Código de cifrado heredado
23 and 24	No prebuilt 32-bit Windows or 32-bit armv7 Linux binaries; macOS 13.5 minimum	Servidores antiguos y dispositivos edge
24	OpenSSL 3.5 at security level 2: RSA, DSA, and DH keys under 2048 bits, ECC keys under 224 bits, and RC4 are prohibited	mTLS y servidores upstream antiguos
24	`tls.createSecurePair` removed; `url.parse()` runtime-deprecated	Código de red heredado
24	Stricter `fetch()` compliance, `AbortSignal` validation, stream and pipe errors now throw	Clientes HTTP y proxies
24	V8 13.6; addons may need C++20	Módulos nativos
25 (if targeting 26)	`SlowBuffer` and `fs.F_OK`, `R_OK`, `W_OK`, `X_OK` removed; Corepack no longer ships	Utilidades antiguas, Yarn o pnpm mediante Corepack
25 (if targeting 26)	IP address as TLS `servername` moved to End-of-Life	Clientes que conecten mediante IP
26	`_stream_*` modules and `writeHeader()` removed; `module.register()` runtime-deprecated; Undici 8	Código de streams antiguo, loaders personalizados

La fila de OpenSSL es la que puede dar problemas de forma silenciosa: su código no cambia en absoluto, pero el handshake con un sistema externo antiguo falla en tiempo de ejecución.

En una rama, actualice .nvmrc, engines, su Dockerfile y su CI a la versión de destino (en un entorno limpio, consulte la guía de instalación de Node.js). Luego reinstale para recompilar los módulos nativos, busque APIs eliminadas, ejecute los codemods oficiales e inicie el servicio con el rastreo de obsolescencias activado:

nvm install 24 && nvm use 24
rm -rf node_modules && npm ci

grep -rnE "assert \{ *type|createCipher\(|createDecipher\(|url\.parse\(|fs\.[FRWX]_OK|SlowBuffer|createSecurePair|_stream_[a-z]+|module\.register\(" \
  --include="*.js" --include="*.mjs" --include="*.ts" --exclude-dir=node_modules .

npx codemod run @nodejs/import-assertions-to-attributes
npx codemod run @nodejs/crypto-createcipheriv-migration
npx codemod run @nodejs/tls-create-secure-pair-to-tls-socket
npx codemod run @nodejs/fs-access-mode-constants

NODE_OPTIONS="--trace-deprecation" npm start

Revise manualmente el resultado de los codemods. El de createCipher es explícito: el código generado no puede descifrar datos cifrados con la API antigua, por lo que deberá planificar una migración de datos si los tiene.

El sitio web de Node.js aún no cuenta con una guía de migración de 24 a 26, por lo que le recomendamos consultar las notas de las versiones 25.0.0 y 26.0.0 para ese salto.

Compruebe que la API se comporta igual en la nueva versión

Las pruebas unitarias no muestran el impacto que una nueva pila TLS y un nuevo cliente HTTP tienen sobre el tráfico real. Ante un salto de dos o tres versiones mayores, conviene hacer una comparación del antes y el después con el servicio en ejecución, y esa es una tarea ideal para su agente de programación.

Apidog CLI permite que Claude Code, Codex o Cursor ejecuten sus suites de pruebas de Apidog directamente desde la terminal. Solo tiene que configurarlo una vez:

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

Luego, indíquele un único prompt a su agente:

My service runs on Node.js 20 in staging. Run Apidog test suite <suiteId> in project
<projectId> against environment <envId> and save reports to reports/node20. When I
redeploy on Node.js 24, run the same suite into reports/node24. List every request
whose status, body, or TLS behavior changed. Then read the service logs for deprecation
warnings and check each failure against the 22, 24, and 25 release notes: removed APIs,
changed defaults, stricter fetch and AbortSignal handling, OpenSSL key size rejections.

El agente ejecutará la misma suite en ambos extremos de la migración:

apidog run --test-suite <suiteId> --project <projectId> -e <envId> \
  -r cli,junit --out-dir reports/node20

# redeploy the service on the target line, restart it

apidog run --test-suite <suiteId> --project <projectId> -e <envId> \
  -r cli,junit --out-dir reports/node24

Dos factores garantizan que la comparación sea fiable:

Nunca pase el parámetro -k. Ese flag desactiva la validación SSL, lo que ocultaría precisamente los errores de TLS que necesita detectar.
Incluya las llamadas que su servicio realiza hacia otros sistemas (upstream). El rechazo de OpenSSL aparecerá como un error de API en un endpoint que dependa de un sistema externo antiguo; por lo tanto, pruebe esas rutas y no se limite a /health.

Una vez superada la migración, mantenga la suite en su canal de CI/CD. La guía de CI/CD con Apidog CLI describe el flujo de trabajo, y el tutorial de Claude Code explica la configuración del agente.

Qué hacer si no puede migrar esta semana

Adquiera versiones parcheadas. La página de End-of-Life de Node.js menciona tres partners a través del programa OpenJS Ecosystem Sustainability Program: HeroDevs ofrece Never-Ending Support con parches de seguridad; TuxCare, mediante Endless Lifecycle Support, adapta parches para versiones en fin de vida; y NodeSource ofrece evaluaciones de actualización y soporte. El proyecto califica esto como una solución temporal, y ciertamente lo es.

Reduzca la superficie de exposición del proceso. Estas medidas disminuyen la exposición a los tipos de fallos descritos anteriormente, aunque no solucionan nada de raíz:

Termine TLS y HTTP/2 en un proxy o balanceador de carga con soporte activo, y comuníquese con Node.js mediante HTTP/1.1 sin cifrar en una red privada.
Deje de descomprimir Brotli procedente de orígenes no confiables, tanto en las peticiones entrantes como en el contenido obtenido de forma externa.
Rechace nombres de host que contengan bytes NUL o representaciones de IP no canónicas antes de cualquier comprobación de lista de permitidos o llamada saliente.
Aísle el servicio: credenciales con el mínimo privilegio, tráfico de salida restringido y sin secretos compartidos con servicios parcheados.

Documente formalmente el riesgo. Asigne un responsable, una fecha límite para la migración y los controles de mitigación implementados, de modo que lo «temporal» tenga un fin definido.

Preguntas frecuentes (FAQ)

¿Node.js 20 sigue teniendo soporte? No. Llegó al final de su ciclo de vida (End-of-Life) el 30 de abril de 2026. La última versión es la 20.20.2 del 24 de marzo de 2026, y el proyecto no publicará ninguna otra.

¿Es Node.js 20 vulnerable a los fallos del 11 de noviembre? Los detalles de las CVE aún no son públicos, por lo que nadie puede asegurar cuáles le afectan. Sin embargo, el aviso oficial señala que las versiones descontinuadas siempre se ven afectadas cuando se produce un lanzamiento de seguridad, y el proyecto no las evalúa individualmente.

¿Debería actualizar a Node.js 22 en su lugar? No. Aunque es el salto más pequeño, su ciclo de vida concluye el 30 de abril de 2027. Migrar a 24 le proporciona un año adicional de soporte, y pasar a 26 le otorga dos años más.

¿Node.js 24 o 26? Elija la 24 si necesita salir del paso esta misma semana o si su infraestructura todavía no es totalmente compatible con la versión 26. Elija la 26 si puede probarlo todo de nuevo en este momento, ya que tendrá soporte hasta el 30 de abril de 2029.

Estoy utilizando Node.js 25. ¿Aplica esto a mi caso? Sí. Node.js 25 llegó al final de su vida útil el 1 de junio de 2026, con la versión 25.9.0 como su última compilación. Tampoco recibirá correcciones en noviembre, y la versión 26 está a solo una versión mayor de distancia.

Cómo encontrar y enriquecer leads con Claude Code

Roobia — Wed, 04 Nov 2026 03:22:45 +0000

Cómo encontrar y enriquecer leads con Claude Code

La API de personas de Firecrawl Alexandria permite a tu agente de programación encontrar y enriquecer personas mediante una sola clave de Firecrawl. Descubres herramientas gratis con v2/search, listas candidatos con Apollo people/search a 0 créditos, revelas uno con Apollo people/match a 30 créditos, o enriqueces un correo electrónico conocido con People Data Labs person/enrich a 60 créditos. Cada llamada pasa por POST /v2/scrape.

Prueba Apidog hoy

Cada paso a continuación aparece dos veces: un prompt para Claude Code (o Codex) y el curl sin procesar, para que puedas automatizarlo sin un agente.

Qué es la API de personas de Firecrawl Alexandria

Alexandria es la biblioteca de proveedores de datos de terceros de Firecrawl, accesible con la clave de API que ya usas para el scraping. Según la documentación de Alexandria, descubres una herramienta, inspeccionas sus entradas y su precio, y luego la ejecutas con scrape. El descubrimiento es gratis; la ejecución cuesta los créditos indicados en la herramienta.

La categoría People contiene 12 proveedores. Dos de ellos cubren la mayor parte del trabajo de prospección:

Proveedor	Capacidad	Créditos por llamada	Qué envías	Qué obtienes
Apollo	`people/search`	0	`person_titles`, `q_keywords`, `q_organization_domains_list`, `per_page` (máx. 100)	Vistas previas: nombre, apellido enmascarado, cargo, empresa, `has_email`, `id` de Apollo
Apollo	`people/match`	30	`id` de la búsqueda, o `linkedin_url`, `email`, o `name` más `domain`	Una persona resuelta con cargo, historial y datos de contacto
People Data Labs	`person/enrich`	60	`email`, `profile`, `pdl_id` y otros; un nombre sin más datos devuelve un 400	Un registro completo de la persona más `likelihood` (1 a 10)

Los precios son los que se muestran junto al botón Run en la página de Apollo y la página de People Data Labs el 4 de noviembre de 2026. La página de Apollo también dice que un fallo de people/match "no devuelve ninguna persona y no se factura".

Cuánto cuesta una búsqueda de personas en dólares

El valor de un crédito depende de tu plan. Según la página de precios de Firecrawl, Hobby cuesta $19 al mes por 5,000 créditos y Standard cuesta $99 al mes por 100,000 créditos, ambos con facturación mensual.

Llamada	Créditos	Hobby ($0.0038/crédito)	Standard ($0.00099/crédito)
Búsqueda de descubrimiento o find-tools	0	$0	$0
Apollo `people/search`	0	$0	$0
Apollo `people/match`	30	$0.114	$0.0297
PDL `person/enrich`	60	$0.228	$0.0594

Las cuentas: $19 / 5,000 = $0.0038 por crédito, y $99 / 100,000 = $0.00099. Buscar 100 vistas previas y revelar las 20 mejores cuesta 600 créditos, lo que cabe dentro de los 1,000 mensuales del plan Free. People Data Labs también te limita a 50,000 llamadas API al año por organización, compartidas entre los endpoints de persona y empresa, incluyendo reintentos.

Paso 1: Conecta Claude Code a Firecrawl

La ruta más rápida es el instalador de agentes de Firecrawl. Añade las habilidades de Firecrawl a cada agente de programación que detecta y te inicia sesión a través del navegador:

npx -y firecrawl-cli@latest init --all --browser

Reinicia tu agente después. De forma manual, es npm install -g firecrawl-cli y firecrawl login. Nuestra guía de Firecrawl CLI cubre ambos, y el recorrido de Firecrawl MCP cubre el servidor MCP, que expone el mismo bucle como firecrawl_search, firecrawl_find_tools y firecrawl_scrape.

Para los ejemplos de curl a continuación, exporta tu clave una vez:

export FIRECRAWL_API_KEY="fc-..."   # never commit this

Paso 2: Descubre las herramientas de personas gratis

Pregunta primero a tu agente, ya que el descubrimiento no cuesta nada:

Use Firecrawl Alexandria to find tools that search people by job title and
company, and tools that enrich a person from an email. Inspect Apollo and
People Data Labs with find-tools and show me each capability's inputs and
credit price before you run anything.

En realidad, eso es una búsqueda con sources establecido solo en ["alexandria"]. Omitir "web" la mantiene gratis, porque los resultados web se facturan:

curl https://api.firecrawl.dev/v2/search \
  -H "Authorization: Bearer $FIRECRAWL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "find people by job title and company", "sources": ["alexandria"], "limit": 5}'

La respuesta lista tools clasificadas, cada una con un proveedor, una capacidad y una descripción. Para leer entradas y precios, el agente ejecuta find-tools:

firecrawl find-tools --options '{"providers":["apollo","people-data-labs"],"level":"tools","expand":["options","response"]}' --include-costs

Paso 3: Busca candidatos en Apollo a 0 créditos

La página de Apollo indica a los agentes que siempre empiecen aquí: es gratis y muestra quién existe antes de que gastes nada.

Run Apollo people/search through Firecrawl Alexandria for "VP of Sales" and
"Head of Revenue" at stripe.com and linear.app, 25 per page. Show name,
title, company and has_email. Don't reveal anyone yet.

La llamada sin procesar:

curl https://api.firecrawl.dev/v2/scrape \
  -H "Authorization: Bearer $FIRECRAWL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "alexandria": {
      "provider": "apollo",
      "capability": "people/search",
      "options": {
        "person_titles": ["VP of Sales", "Head of Revenue"],
        "q_organization_domains_list": ["stripe.com", "linear.app"],
        "page": 1,
        "per_page": 25
      }
    }
  }'

Cada vista previa lleva un apellido enmascarado y un id de Apollo, la entrada más fiable para el siguiente paso.

Paso 4: Revela una persona con people/match

Ahora paga solo por las personas que vale la pena contactar, a 30 créditos por coincidencia:

For the 3 previews with has_email true, run Apollo people/match with their
id. Don't set reveal_personal_emails or reveal_phone_number.

curl https://api.firecrawl.dev/v2/scrape \
  -H "Authorization: Bearer $FIRECRAWL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"alexandria": {"provider": "apollo", "capability": "people/match", "options": {"id": "<apollo_id>"}}}'

Deja las dos flags de revelado desactivadas a menos que las necesites. La página de Apollo dice que un correo personal "cuesta extra" y que un número de teléfono es "sustancialmente más caro que la coincidencia base".

Paso 5: Enriquece un correo conocido con People Data Labs

Cuando ya tienes un correo electrónico, por ejemplo de un registro entrante, person/enrich devuelve un perfil más completo: correo de trabajo, cargo, empresa, URL de LinkedIn, experiencia y habilidades.

Enrich jane@example.com with People Data Labs person/enrich through
Firecrawl Alexandria. Set min_likelihood to 6 so a weak match comes back
as a 404 instead of a wrong record.

curl https://api.firecrawl.dev/v2/scrape \
  -H "Authorization: Bearer $FIRECRAWL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"alexandria": {"provider": "people-data-labs", "capability": "person/enrich", "options": {"email": "jane@example.com", "min_likelihood": 6}}}'

min_likelihood va de 1 a 10 con un valor predeterminado de 2. La página del proveedor plantea el equilibrio con claridad: un 404 "es gratis aquí y un registro incorrecto no lo es". Súbelo antes de recorrer una lista.

Maneja THIRD_PARTY_DATA_TERMS_REQUIRED

Tu primera llamada de pago a un proveedor puede fallar con THIRD_PARTY_DATA_TERMS_REQUIRED. Según la documentación, el error incluye una requiresAction.url, y un administrador de la organización tiene que abrirla y aceptar los términos de ese proveedor antes de que se realice cualquier llamada.

No dejes que el agente haga clic en ella. La documentación dice que los agentes necesitan autorización explícita del usuario antes de aceptar términos, que rigen cómo puedes usar datos personales. Añade una línea a tu CLAUDE.md: "Si una llamada devuelve THIRD_PARTY_DATA_TERMS_REQUIRED, detente y muéstrame requiresAction.url."

Lee el payload de alexandria[].data

Los resultados vuelven en un array alexandria, una entrada por llamada de herramienta, con el payload del proveedor bajo data. HTTP sin procesar envuelve todo el resultado del SDK en un data de nivel superior, así que en una respuesta de curl la coincidencia de Apollo está en data.alexandria[0].data.person:

curl -s https://api.firecrawl.dev/v2/scrape ... | jq '.data.alexandria[0].data.person | {name, title, email, linkedin_url}'

Dos comprobaciones evitan que filas incorrectas entren en tu CRM:

Comprueba si hay errores en cada resultado antes de leer data. La documentación lo dice explícitamente; una sola llamada puede fallar mientras la solicitud HTTP tiene éxito.
Trata los correos de marcador de posición como ausentes. Apollo señala que un correo no revelado puede volver como el literal email_not_unlocked@domain.com, incluso cuando email_status dice verificado.

Para People Data Labs, la persona está bajo data dentro del resultado, junto al status y likelihood del envelope.

Envía feedback y recupera un crédito

Alexandria te paga por feedback. Cada envío reembolsa 1 crédito por cualquier valoración, con un límite por día UTC de 10 créditos por sitio web y 100 por equipo. Tienes 20 minutos desde la última llamada a Alexandria de tu equipo; después de eso recibes FEEDBACK_WINDOW_EXPIRED.

Desde la CLI, ejecuta firecrawl alexandria feedback (consulta --help para las opciones). Por MCP, el agente llama a firecrawl_feedback con endpoint: "alexandria". Una línea de prompt funciona bien: "Si un resultado parece incorrecto o vacío, envía feedback a Alexandria describiéndolo."

Deja que Claude Code proteja estas llamadas con Apidog CLI

Una vez que un script depende de que people/search devuelva un id que people/match acepte, un campo renombrado lo rompe silenciosamente. Tu agente puede convertir las llamadas de esta guía en un escenario de regresión en Apidog CLI y ejecutarlo según una programación. Tú escribes un prompt.

Configura la CLI y su skill de agente una vez:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_APIDOG_TOKEN>
npx -y skills add https://apidog.com   # pick Claude Code or Codex when prompted

Luego dale a Claude Code este [REDACTED PROMPT]
Write an OpenAPI 3 file for three Firecrawl calls from this guide:
POST /v2/search with sources ["alexandria"], POST /v2/scrape for apollo
people/search (per_page 1), and POST /v2/scrape for apollo people/match.
All send Authorization: Bearer {{FIRECRAWL_API_KEY}}. Import it into Apidog
project and create a "Firecrawl" environment for
https://api.firecrawl.dev. Build a test scenario that runs the three in
order, saves data.alexandria[0].data.people[0].id as personId and passes it
to people/match, and asserts status 200, no result error, and a person
object on the match. Run it and summarize failures.


El agente lee el esquema de cada payload, lo valida y luego ejecuta comandos como estos:

bash
apidog import --project --format openapi --file ./firecrawl-people.json
apidog environment create Firecrawl --project --base-url https://api.firecrawl.dev
apidog test-scenario create --project --name "Alexandria people" --folder-id --priority
apidog cli-schema get test-scenario-update
apidog cli-schema validate test-scenario-update --file ./people-scenario.json
apidog test-scenario update --project --file ./people-scenario.json
apidog run -t --project -e \
--env-var "FIRECRAWL_API_KEY=$FIRECRAWL_API_KEY" -r cli,junit




![Diagram of an Apidog test scenario chaining Firecrawl v2/search, Apollo people/search and Apollo people/match, run by a coding agent with apidog run and producing a test report](https://assets.apidog.com/blog-next/2026/11/firecrawl-alexandria-people-api-apidog-scenario.png)

Cada ejecución completa cuesta 30 créditos por la coincidencia, así que prográmala a diario en lugar de en cada commit. La [referencia de apidog run](https://apidog.com/es/blog/apidog-run-command-reference?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) lista las flags de informe e iteración, y [Apidog CLI en Claude Code](https://apidog.com/es/blog/apidog-cli-in-claude-code?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) muestra la configuración con más profundidad. El plan Free de Apidog cubre hasta 4 usuarios.

  
  


## Preguntas frecuentes

**¿La API de personas de Firecrawl Alexandria es gratis?** El descubrimiento es gratis, y Apollo `people/search` mostraba 0 créditos el 4 de noviembre de 2026. Revelar una persona cuesta créditos: 30 para Apollo `people/match` y 60 para People Data Labs `person/enrich`. El plan Free incluye 1,000 créditos al mes sin tarjeta.

**¿Necesito cuentas separadas de Apollo o People Data Labs?** No. Alexandria ejecuta ambos a través de tu clave de API de Firecrawl y factura en créditos de Firecrawl. Un administrador de la organización sí necesita aceptar los términos de cada proveedor una vez, que es lo que pide `THIRD_PARTY_DATA_TERMS_REQUIRED`.

**¿Por qué mi respuesta de people/match muestra [email_not_unlocked@domain.com](mailto:email_not_unlocked@domain.com)?** Ese es el marcador de posición de Apollo para un correo que no se reveló. Trátalo como no disponible, incluso si `email_status` dice verificado.

**¿Pueden Codex o Cursor ejecutar esto en lugar de Claude Code?** Sí. `npx -y firecrawl-cli@latest init --all` configura cada agente detectado, y las herramientas MCP funcionan en cualquier cliente MCP. Las llamadas de `curl` funcionan sin ningún agente.

**¿Cómo evito pagar por coincidencias incorrectas?** Busca antes de hacer match, haz match por `id` de Apollo en lugar de por nombre, y establece `min_likelihood` en 6 o más en People Data Labs. Apollo no factura un fallo, y un 404 de PDL es gratis.

Reseña de FinFeedAPI: API de datos de mercados de predicción multi-exchange

Roobia — Tue, 03 Nov 2026 10:18:21 +0000

Reseña de FinFeedAPI: API de datos de mercados de predicción multi-exchange

Imagina que quieres seguir cómo el mercado valora un único evento económico en Kalshi, Polymarket y ForecastEx. Sobre el papel, suena como un panel sencillo. En la práctica, implica tres API diferentes, tres formas de identificar el mismo mercado y tres formatos de respuesta que conciliar antes de poder dibujar un solo gráfico.

Prueba Apidog hoy

Ese problema crece con cada nueva plataforma. Los mercados de predicción ahora abarcan exchanges regulados de EE. UU., protocolos en cadena, comunidades de dinero ficticio y contratos de eventos de plataformas cripto establecidas, y ninguno comparte un modelo de datos común.

Esta es la brecha que FinFeedAPI está diseñada para cubrir. Su API de mercados de predicción reúne nueve plataformas bajo un único esquema estandarizado, para que los desarrolladores puedan consultar mercados, operaciones, libros de órdenes e historial de la misma forma, sin importar de dónde vengan los datos.

Para los desarrolladores, ese crecimiento viene con una verdad incómoda. Cada plataforma expone su propia API, sus propios identificadores de mercado, sus propias convenciones de nombres y su propia idea de cómo es un "mercado". ¿Quieres un panel que siga el mismo evento en tres plataformas? Ahora mantienes tres integraciones, tres modelos de datos y tres conjuntos de casos límite.

Ese es exactamente el problema que FinFeedAPI intenta resolver.

En esta reseña, repasaré qué cubre la API de mercados de predicción de FinFeedAPI, qué datos obtienes realmente, cómo se ven los endpoints en la práctica, cuánto cuesta y en qué se queda corta, para que puedas decidir si encaja en tu stack.

TL;DR


Proveedor	FinFeedAPI de API Bricks (también detrás de CoinAPI)
Plataformas cubiertas	9 plataformas de mercados de predicción
Datos	Mercados y metadatos, operaciones, cotizaciones, libros de órdenes, OHLCV, archivos planos históricos
Acceso	REST, JSON-RPC, servidor MCP alojado, archivos planos (S3)
Modo	Datos de mercado de solo lectura, solicitud-respuesta (sin stream WebSocket)
Precios	Créditos gratis para empezar, luego pago por uso desde $1 por cada 1000 solicitudes
Ideal para	Paneles entre plataformas, investigación, backtesting, agentes de IA

¿Qué es FinFeedAPI?

FinFeedAPI es un proveedor de datos financieros creado por API Bricks, la misma empresa detrás de CoinAPI. Junto con sus API de acciones, divisas y SEC, ofrece una API de mercados de predicción que te da acceso estandarizado a datos de mercado de nueve plataformas de mercados de predicción mediante una sola integración.

La idea es sencilla: en lugar de aprender nueve API, aprendes una. Los ID de mercado, los resultados, las marcas de tiempo y las estructuras de respuesta siguen el mismo esquema sin importar de qué plataforma provengan los datos.

Algunos detalles de ingeniería me llamaron la atención al revisar la documentación:

Modelo de datos unificado en todas las plataformas compatibles
ID de mercado estandarizados que incluyen el resultado, por ejemplo ..._YES y ..._NO
Marcas de tiempo ISO 8601 UTC en todos los endpoints
Precisión numérica consistente, de hasta 19 dígitos con 9 decimales
Cuatro formas de acceso: REST, JSON-RPC, un servidor MCP alojado y archivos planos

Algo que conviene aclarar desde el principio: FinFeedAPI es una capa de datos de mercado de solo lectura. No coloca órdenes. Si tu producto necesita ejecución, seguirás usando la API nativa de cada plataforma para esa parte.

Plataformas de mercados de predicción compatibles

Actualmente, FinFeedAPI cubre nueve plataformas, que abarcan exchanges regulados, protocolos descentralizados, mercados de resultados en cadena y una comunidad de dinero ficticio.

Plataforma	Tipo	Qué cubre
Polymarket	Descentralizado	Política, economía, cripto, deportes y eventos globales
Kalshi	Regulado (CFTC)	Contratos de eventos de EE. UU. sobre indicadores económicos, elecciones, clima, deportes y más
ForecastEx	Regulado (CFTC)	Contratos de eventos de EE. UU., incluidos resultados económicos y financieros
Gemini Prediction Markets	Regulado	Contratos de eventos sobre deportes, cripto, economía, política y otros temas
Crypto.com Prediction Markets	Regulado	Contratos basados en eventos en la plataforma de mercados de predicción de Crypto.com
Myriad	Descentralizado	Cripto, eventos de actualidad y otros resultados
Pascal	Descentralizado	Mercados de predicción sin custodia construidos sobre Solana
Hyperliquid Outcome Markets (HIP-4)	Mercados de resultados en cadena	Contratos de eventos binarios y de múltiples resultados sobre la infraestructura nativa de Hyperliquid
Manifold Markets	Social, dinero ficticio	Mercados impulsados por la comunidad sobre una amplia variedad de temas

La combinación es lo que hace esto interesante. Comparar cómo una plataforma regulada, una nativa de cripto y una multitud de dinero ficticio valoran el mismo evento es donde la investigación entre plataformas se vuelve valiosa. También es donde un esquema normalizado ahorra más tiempo.

¿A qué datos puedes acceder?

Aquí es donde FinFeedAPI se gana su lugar. La mayoría de las herramientas de mercados de predicción se detienen en el último precio. FinFeedAPI expone el mercado completo, desde el descubrimiento hasta la profundidad del libro de órdenes y el historial.

Todos los endpoints REST se encuentran bajo https://api.prediction-markets.finfeedapi.com/v1.

Conjunto de datos	Endpoint	Qué obtienes
Exchanges	`GET /exchanges` y `/exchanges/{exchange_id}`	Plataformas compatibles, ID de exchange, descripciones, sitios web
Mercados activos	`GET /markets/{exchange_id}/active`	Una lista compacta de ID de mercados actualmente activos
Listados de mercados	`GET /markets/{exchange_id}/history`	Registros completos de mercados con paginación basada en cursor: títulos, descripciones, resultados, precios, estado
Mercado individual	`GET /markets/{exchange_id}/{market_id}`	Metadatos de un mercado
Actividad actual	`GET /activity/{exchange_id}/{market_id}/current`	Última operación más el último bid y ask
Actividad reciente	`GET /activity/{exchange_id}/{market_id}/latest`	Operaciones recientes y actualizaciones de cotizaciones
Operaciones y cotizaciones históricas	`GET /activity/{exchange_id}/{market_id}/history/trades` y `/history/quotes`	Registros históricos servidos desde archivos planos
Libro de órdenes actual	`GET /orderbook/{exchange_id}/{market_id}/current`	Bids y asks para un resultado de mercado
Libro de órdenes histórico	`GET /orderbook/{exchange_id}/{market_id}/history`	Eventos brutos de órdenes limitadas (altas, actualizaciones, eliminaciones) para reconstruir el libro
OHLCV	`GET /ohlcv/periods`, `/ohlcv/{exchange_id}/{market_id}/history`, `/latest`, `/ohlcv/{exchange_id}/history`	Velas con apertura, máximo, mínimo, cierre, volumen y número de operaciones

Algunas cosas que conviene saber:

El descubrimiento es en dos pasos. El endpoint /active solo devuelve ID, porque se deriva de cotizaciones y operaciones recientes. Para obtener todos los detalles, llama a /history o al endpoint de mercado individual.
Los periodos OHLCV van desde segundos hasta años, y las velas históricas se devuelven en orden temporal ascendente, que es lo que quieres para backtesting.
Los datos históricos del libro de órdenes son a nivel de evento, no solo instantáneas. Eso abre la puerta a la reproducción de mercado y la investigación de liquidez.
Los datos de ciclo de vida y resolución cubren estados abiertos, cerrados, resueltos y suspendidos, con información de resolución donde la plataforma de origen la admite.

Primeros pasos: tus primeras solicitudes

El registro es rápido. Creas una cuenta gratuita, generas una clave de API desde la consola y empiezas con créditos gratis.

Para REST y JSON-RPC, pasas la clave en el encabezado Authorization. La documentación también acepta X-APIKey, X-APIBricks-Key y X-CoinAPI-Key.

1. Lista los exchanges compatibles

Empieza aquí para obtener los valores exactos de exchange_id que usarás en todo lo demás.

curl -X GET "https://api.prediction-markets.finfeedapi.com/v1/exchanges" \
  -H "[REDACTED CREDENTIAL]

2. Descubre mercados activos

curl -X GET "https://api.prediction-markets.finfeedapi.com/v1/markets/POLYMARKET/active?limit=10" \
  -H "[REDACTED CREDENTIAL]

Esto devuelve una lista simple de ID de mercado, cada uno con su resultado incorporado:

[
  "WILL-TRUMP-SELL-10K-25K-GOLD-CARDS-IN-2025_YES",
  "WILL-TRUMP-SELL-10K-25K-GOLD-CARDS-IN-2025_NO",
  "NFL-PIT-CAR-2025-08-21-SPREAD-AWAY-5PT5_YES"
]

3. Obtén la última operación y cotización

curl -X GET \
  "https://api.prediction-markets.finfeedapi.com/v1/activity/POLYMARKET/WILL-TRUMP-SELL-10K-25K-GOLD-CARDS-IN-2025_YES/current" \
  -H "[REDACTED CREDENTIAL]

La respuesta te da la última operación junto con el último bid y ask para ese resultado.

4. Extrae OHLCV histórico en Python

Esta es la llamada a la que recurriría primero al crear un gráfico de probabilidad o un backtest.

import requests

[REDACTED CREDENTIAL]
BASE = "https://api.prediction-markets.finfeedapi.com/v1"
headers = {[REDACTED CREDENTIAL]}

market_id = "WILL-TRUMP-SELL-10K-25K-GOLD-CARDS-IN-2025_YES"

resp = requests.get(
    f"{BASE}/ohlcv/POLYMARKET/{market_id}/history",
    headers=headers,
    params={"period_id": "1DAY", "limit": 30},
)
resp.raise_for_status()

for candle in resp.json():
    print(candle["time_period_start"], candle["price_close"], candle["volume_traded"])

Cada vela incluye time_period_start, time_period_end, price_open, price_high, price_low, price_close, volume_traded y trades_count. Llama a /ohlcv/periods para ver todos los period_id compatibles.

5. Consulta la profundidad del libro de órdenes

curl -X GET \
  "https://api.prediction-markets.finfeedapi.com/v1/orderbook/POLYMARKET/WILL-TRUMP-SELL-10K-25K-GOLD-CARDS-IN-2025_YES/current" \
  -H "[REDACTED CREDENTIAL]

La instantánea devuelve exchange_id, market_id, time_exchange, time_coinapi, además de los arrays bids y asks. Eso es suficiente para calcular spreads y desequilibrio en la parte superior del libro.

Si prefieres no escribir HTTP sin procesar, API Bricks publica SDK oficiales (Python, Node.js, Go, C# y otros) en su repositorio de SDK en GitHub.

Más allá de REST: MCP, JSON-RPC y archivos planos

Cada interfaz expone los mismos conjuntos de datos estandarizados. Tú eliges la que se adapte a tu arquitectura.

Interfaz	Encabezado de autenticación	Ideal para
API REST	`Authorization`	Paneles, analítica, aplicaciones en producción
API JSON-RPC	`Authorization`	Servicios que prefieren llamadas estilo RPC sobre los mismos datos
Servidor MCP alojado	`X-APIKey`	Asistentes de IA, agentes de programación, flujos de trabajo de investigación
Archivos planos (S3)	Credenciales compatibles con S3	Historial masivo para backtesting y machine learning

El servidor MCP es lo más destacado

Desde mi perspectiva, esta es la parte más visionaria del producto. En lugar de enseñarle a un agente tu documentación de API, lo apuntas a un endpoint MCP alojado y él descubre las herramientas por sí mismo.

La configuración son unas pocas líneas en Cursor, Claude Desktop o cualquier cliente compatible con MCP:

{
  "mcpServers": {
    "FinFeedAPI-Prediction-Markets": {
      "url": "https://api.prediction-markets.finfeedapi.com/mcp",
      "headers": {
        [REDACTED CREDENTIAL]
      }
    }
  }
}

Actualmente, el servidor expone herramientas para:

Descubrimiento de exchanges: exchanges_list, exchanges_get
Descubrimiento de mercados: markets_get_active, markets_get_history
Actividad en vivo: activity_get_current, activity_get_latest
Operaciones y cotizaciones históricas: activity_get_trades_history, activity_get_quotes_history
OHLCV: ohlcv_list_periods, ohlcv_get_latest_market, ohlcv_get_history_market, ohlcv_get_history_exchange
Libros de órdenes: orderbook_get_current, orderbook_get_history

Eso significa que puedes pedirle a un agente algo como "encuentra los mercados de Kalshi más activos y muéstrame cómo se movieron sus probabilidades esta semana" y puede encadenar por su cuenta llamadas de descubrimiento, actividad y OHLCV.

Una nota si configuras una conexión MCP de FinFeedAPI más antigua: el endpoint pasó de /sse a /mcp, así que las configuraciones antiguas deben actualizarse.

Archivos planos para historial pesado

Para investigación a gran escala, extraer años de datos mediante llamadas REST paginadas es lento. Los archivos planos te dan operaciones, cotizaciones, libros de órdenes y OHLCV de forma masiva a través de una API compatible con S3, para que puedas usar las herramientas y SDK de S3 que ya conoces.

Precios

FinFeedAPI usa precios basados en el uso y en créditos. Empiezas con créditos gratis y luego pagas por solicitud.

En Pago por uso, las primeras 1000 solicitudes por día cuestan $5 por cada 1000, y todo lo que supere las 1000 por día baja a $1 por cada 1000. Los planes comprometidos reducen esa tarifa.

Plan	Mensual	Tarifa por crédito	Extras destacados
Pago por uso	Sin compromiso	$1.00	Soporte por IA y correo electrónico, registro autoservicio
Comprometido 64	$64	$0.85	Registro asistido por IA
Comprometido 256	$256	$0.75	Registro asistido por IA
Comprometido 512	$512	$0.70	Soporte por Slack, canal de Slack dedicado
Comprometido 1024	$1,024	$0.65	SLA de disponibilidad del 99.9%, representante de éxito del cliente, registro con asistencia humana
Enterprise	Personalizado	Personalizado	SLA personalizados, optimizaciones de latencia, infraestructura dedicada

Los planes comprometidos no reducen lo que usas. Te dan más créditos por el mismo gasto, y una vez que se agotan esos créditos, el uso adicional se factura a la tarifa de Pago por uso. También hay facturación anual disponible.

Mi opinión: para prototipos e investigación, Pago por uso está bien. Si consultas muchos mercados cada pocos segundos, calcula primero los números. FinFeedAPI publica casos de uso de precios para paneles, monitoreo de libros de órdenes y rellenos históricos OHLCV que hacen que estimar sea mucho más fácil.

Dónde se queda corta FinFeedAPI

Ninguna API es perfecta, y una reseña que omite las desventajas no sirve de mucho. Esto es lo que debes tener en cuenta:

Sin ejecución de órdenes. Es solo una capa de datos. Los bots de trading aún necesitan las API nativas de las plataformas para colocar órdenes.
Sin stream WebSocket para mercados de predicción. Los datos actuales llegan mediante llamadas de solicitud-respuesta, así que "en vivo" significa polling. Para estrategias sensibles a la latencia, eso es una restricción real, y el polling frecuente aumenta tu factura.
Las primeras 1000 solicitudes diarias son las más caras. A $5 por cada 1000 frente a $1 por cada 1000 después, los proyectos muy pequeños pagan una tarifa efectiva más alta que los que tienen mucho tráfico.
Los datos de resolución dependen de la fuente. Los detalles del ciclo de vida y la resolución son tan completos como lo que expone cada plataforma.
La normalización es un compromiso. Un esquema unificado es el objetivo, pero si dependes de un campo único de una plataforma, revisa las muestras de datos antes de comprometerte.

Ninguna de estas es un impedimento para casos de uso de analítica, investigación o IA. Importan más si estás construyendo un sistema de trading de alta frecuencia.

¿Quién debería usar FinFeedAPI?

Puntos fuertes

Nueve plataformas de mercados de predicción tras un solo esquema
Ciclo de vida completo del mercado: descubrimiento, operaciones, cotizaciones, libros de órdenes, OHLCV, historial
Datos históricos del libro de órdenes a nivel de evento para reproducción
Servidor MCP alojado que funciona con Cursor y Claude Desktop
Archivos planos masivos para investigación y machine learning
Precios basados en uso con créditos gratis para empezar

Ideal para

Paneles multiplataforma que comparan probabilidades entre plataformas
Investigadores y analistas cuantitativos que hacen backtesting de estrategias de mercados de predicción
Equipos de pronóstico y ML que necesitan OHLCV histórico limpio
Analítica de liquidez basada en la profundidad del libro de órdenes y los spreads
Equipos de IA que crean agentes que razonan sobre eventos del mundo real
Investigación académica y económica sobre cómo las multitudes valoran los resultados

Probablemente no para

Bots que necesitan colocar órdenes
Estrategias que necesitan un stream push de subsegundo

Reflexiones finales

Los mercados de predicción crecen más rápido de lo que la mayoría de los equipos puede integrarlos. Cada nueva plataforma trae nuevos identificadores, nuevos formatos y nuevo trabajo de mantenimiento.

FinFeedAPI no intenta ser un exchange. Se centra en una sola tarea: convertir nueve plataformas fragmentadas en una capa de datos consistente. Mercados, operaciones, cotizaciones, libros de órdenes, OHLCV e historial profundo vuelven todos con la misma forma, a través de REST, JSON-RPC, MCP o archivos planos.

Ten en cuenta desde el principio que es de solo lectura y de solicitud-respuesta, y encaja en una amplia variedad de productos, desde paneles de pronóstico hasta agentes de investigación con IA.

Nueve plataformas. Un esquema. Una clave de API. Menos fontanería, más construcción.

Sitio web: finfeedapi.com/products/prediction-markets-api

Documentación de la API: Documentación de la API REST de mercados de predicción