La suerte no tiene API

La Lotería de Navidad no publica una API: SELAE devuelve 403 a cualquier consulta automatizada, así que el resultado del 22 de diciembre llega al público por una cadena de históricos en CSV, APIs de terceros y webs que lo maquetan. Esa cadena decide dos cosas que se juegan en segundos: si el dato es correcto y si la web aguanta el pico. Este es el recorrido, con las cuatro arquitecturas que lo resuelven hoy y lo que cada una deja en el registro del visitante.

22 de diciembre, 20:07. El Gordo ya ha salido. En algún sitio, alguien recarga por cuarta vez en diez segundos la misma web de resultados, con el móvil en una mano y el décimo en la otra, y esa web tiene que decidir si responde con el número correcto o con una página de error. No hay término medio útil: o el dato está, o el visitante se va a comprobarlo a otro sitio y no vuelve.

Ese instante explica casi todo lo que hay detrás de este negocio. La edición de 2026 reparte 2.870 millones de euros en premios, 98 más que el año pasado, sobre una emisión de 4.100 millones, según los datos de la presentación de SELAE del 6 de noviembre. Y sin embargo, la institución que organiza el sorteo más seguido del país no ofrece una API pública para consultar el resultado. Su web responde 403 a una petición automatizada normal. La respuesta no identifica el sistema que hay detrás, pero es el comportamiento habitual de un cortafuegos de aplicaciones, y en cualquier caso hace su trabajo: si no lo hiciera, el 22 de diciembre a las 20:07 no respondería a nadie.

Las tres familias de webs de lotería

Alrededor de ese vacío hay tres familias de webs.

La primera quiere saber qué ha salido, y saberlo antes que los demás. Son las webs de resultados, las hemerotecas, las alertas.

La segunda no dice qué ha salido: dice qué número elegir. Números más repetidos, terminaciones que salen más, los que llevan años sin aparecer, calculadoras de probabilidad, sistemas reducidos.

La tercera vive del hueco que deja la segunda. Mentalistas que anuncian el Gordo en enero, horóscopos con número recomendado, aplicaciones que prometen el número de tu signo. Y desde hace dos años, medios que publican el número que supuestamente va a salir según un modelo de lenguaje: La Verdad lo hizo en septiembre con el 73427, el 18913 y el 64268, eso sí, advirtiendo en el mismo texto de que era «totalmente por diversión» y de que «no se puede predecir».

Las tres usan los mismos datos. Lo que cambia es qué hacen con la incertidumbre: medirla, venderla o disimularla.

En Navidad el bombo tiene 100.000 números posibles, del 00000 al 99999, y cada uno tiene exactamente la misma probabilidad. Un número que ha salido dos veces no está «caliente». Uno que no ha salido nunca no está «a punto». La urna no recuerda. Cualquier web que insinúe lo contrario vende una intuición, aunque el gráfico que la acompaña sea correcto.

Lo que sí es una decisión real es otra cosa, y casi nadie la pone en el centro: cuánto dinero pones y con cuánta gente compartes el número. Un décimo cuesta 20 euros y el sorteo reparte alrededor del 70 % de la emisión. El resto no vuelve. Jugar diez décimos del mismo número no mejora la probabilidad de acertar el Gordo: multiplica por diez el coste y por diez el premio si toca. Lo que no mejora en ningún caso es la probabilidad por euro jugado.

La excepción son los sistemas reducidos, que sí son matemática de verdad. Son diseños de recubrimiento: estructuras combinatorias que garantizan un premio de categoría inferior si una parte de los números elegidos aparece en el sorteo. Reparten el riesgo entre muchas combinaciones en lugar de concentrarlo en una. No mejoran la probabilidad de acertar. En la publicidad, las dos cosas se presentan como la misma.

Y cuando una familia insinúa que el número se puede elegir, alguien acaba afirmando que él ya sabe cuál va a salir. El caso clásico es el de Anthony Blake, que en 2002 escribió el 08103 en un libro, lo encerró en una urna con tres llaves y lo abrió en directo cuando el número ya había salido. La Razón ha documentado también el del mago Xerax, que lo consiguió tres años seguidos, entre 2008 y 2010. Tres aciertos consecutivos de uno entre cien mil tienen una probabilidad de uno entre mil billones. Cuando el cálculo descarta la casualidad, queda el procedimiento. En magia, el procedimiento se llama truco.

El coste marginal de producir esa narración ha caído a cero con los modelos generativos, y por eso hay más que nunca. La familia que vende certeza necesita que la familia anterior siga pareciendo ciencia.

De dónde salen los datos del sorteo

Aquí empieza la parte que el visitante no ve, y es la que decide la calidad de todo lo demás.

El eslabón de origen es un histórico gratuito en CSV: La Web de la Primitiva, que arrastra décadas de sorteos y responde con la cabecera X-Powered-By: PHP/5.4. Un servidor con una versión de PHP retirada hace años sostiene buena parte del archivo histórico que circula en España. Nadie tiene incentivo en reescribir lo que ya funciona. Y cuando el archivo de un país depende de una máquina así, el país entero tiene un problema de soberanía tecnológica.

El segundo eslabón son las APIs de terceros. LoteriasAPI convierte la ausencia de API oficial en un producto: JSON, planes y una capa de Cloudflare delante. Donde el organismo público no llega, alguien pone una interfaz y cobra por ella.

El tercero son las webs que muestran el resultado. Algunas tiran de PDFs oficiales, otras de históricos de terceros, otras de una API propia que a su vez depende de las anteriores. En la práctica, casi todo el país consulta el mismo dato a través de dos o tres intermediarios que no aparecen en ningún pie de página.

Por qué validar el histórico es lo que importa

Descargar un CSV es media hora. Comprobar que no tiene huecos, que no tiene duplicados y que las unidades son las correctas lleva años, porque los errores no se ven: se publican.

Dos casos del histórico de Navidad que mantenemos.

El primero es de unidades. Un día, los premios empezaron a valer diez veces más de lo que valen. La causa no era un sorteo extraordinario: la lista oficial da el importe por serie, y una serie son diez décimos. Multiplicar por diez el importe de cada fila convertía 400.000 euros en cuatro millones. El dato era correcto. La unidad, no.

El segundo es más fino. Un DISTINCT sobre número y sorteo eliminaba casi mil filas del sorteo de 2014, el del Gordo 13.437 y el tercer premio 07.637. Los dos premios compartían las dos últimas cifras, así que un mismo número podía aparecer en dos filas de premio y las dos eran ciertas. La clave única estaba mal elegida. En un sorteo, la identidad de una fila no es el número: es el número más el premio.

Los dos errores tienen la misma forma. El sistema hacía exactamente lo que se le había pedido, y lo que se le había pedido estaba mal. Por eso la validación no se resuelve con más código, sino con una decisión previa sobre qué significa cada columna. Y por eso conviene escribirla antes de tener prisa.

Cuatro arquitecturas para servir el resultado

Con el dato validado, queda servirlo. Aquí no hay una respuesta correcta: hay cuatro formas distintas de resolver el mismo problema, y las cuatro funcionan.

Una de las cuatro webs, BomboLab, es un proyecto de Aliantha SL, empresa de la que es CEO una colaboradora de este medio, y se alimenta de la API de LoteriasAPI, que este artículo también cita. Los datos de las tablas están medidos y fechados, y el artículo compara arquitecturas, no rendimiento comercial.

Sitio	Qué sirve hoy	Cómo encara el pico
euromillones.org.es	Next.js tras Cloudflare	Render en servidor y CDN por delante
loteriasapi.com	Angular 20 tras Cloudflare	Aplicación de cliente contra su propia API
cuandomevaatocar.com	LiteSpeed con PHP y PHPSESSID	Página generada por servidor con sesión
bombolab.es	HTML estático; PHP solo en /resultados/	Fichero que se regenera, sin consulta por visita

Ninguna es «la buena». Un Next.js detrás de Cloudflare reparte el coste del render entre el servidor y la caché. Una aplicación Angular traslada el trabajo al navegador y concentra la carga en la API. Un PHP con LiteSpeed resuelve cada visita en el servidor, con la ventaja de que controla todo y el inconveniente de que nada se comparte entre visitantes. Un estático sirve el mismo fichero a todo el mundo y no puede fallar por carga, pero depende de que la actualización llegue a tiempo.

La decisión importa menos de lo que parece en noviembre. En diciembre, decide.

Qué pasa el 22 de diciembre a las 20:07

La noche del 22 de diciembre, el tráfico de estas webs no crece: se multiplica en cuestión de segundos. Y no todas las arquitecturas lo aguantan igual.

Hay una medida que se puede tomar hoy, con la web en calma. Es el tamaño del HTML de la portada, sin contar imágenes ni scripts, medido con curl el 11 de noviembre de 2026:

Sitio	HTML de portada
euromillones.org.es	524 KB
loteriasapi.com	227 KB
cuandomevaatocar.com	88 KB
bombolab.es	31 KB

Son páginas distintas y la comparación no es del todo justa, pero el orden de magnitud sí lo es: diecisiete veces más HTML para el mismo contenido. En fibra da igual. En un móvil con mala cobertura, en el salón de casa de un familiar, con la wifi saturada por veinte personas mirando lo mismo, no da igual: el navegador tiene que descargar y procesar cada kilobyte antes de pintar el número.

El segundo detalle es la caché del CDN. Si el resultado se guarda un minuto, la web sirve un número viejo durante sesenta segundos justo cuando todo el mundo está mirando. Si se guarda un segundo, cada visita vuelve a preguntar al origen y la memoria caché deja de servir para lo único que hacía falta. La salida habitual es un fichero estático que se reemplaza de golpe y una cabecera que obliga a revalidar: la primera petición después del cambio paga el coste, las siguientes no.

El tercer problema no es de la web, es de la cadena. Una web que consulta una API externa en cada visita hereda su latencia y sus límites. Si esa API se cae a las 20:07, la web se cae con ella, aunque su servidor esté perfectamente sano. Y si la fuente tarda en publicar, hay que elegir entre esperar o publicar un resultado sin verificar. La validación previa parece una pérdida de segundos hasta la primera vez que evita un error.

La carrera por publicar el número primero

Cada año hay una competición por publicar el número antes, y casi siempre la gana quien no debería.

Publicar antes no sirve de mucho si Google no tiene la URL. El resultado del 22 de diciembre compite contra páginas que llevan meses posicionadas con la misma consulta, y una URL nueva tarda en indexarse. Por eso el sitemap importa más ese día que el resto del año: no por el sitemap en sí, sino porque una URL que existe desde noviembre con un lastmod que se actualiza tiene una ventaja que una URL creada a las 20:07 no tiene.

La estrategia que funciona es aburrida: una URL por sorteo, publicada antes del sorteo, con el contenido correcto y actualizada cuando llega el dato. Nada de páginas nuevas cada año. El día del pico, la infraestructura solo tiene que cambiar un número.

Qué se guarda cuando compruebas tu décimo

Queda un detalle que casi nadie mira y que es el más incómodo.

Cuando alguien comprueba un número en una web, ese número suele viajar en la URL. Una URL con el décimo dentro acaba en los registros del servidor, en las métricas de analítica y, si el visitante comparte el enlace, en el historial de otra persona. No es un dato de salud, pero sí es un dato personal que nadie pidió guardar.

En las cuatro webs de la tabla anterior hay analítica en el HTML inicial. Ninguna sirve un contenedor de Google Tag Manager: tres usan gtag.js y la cuarta sigue con Universal Analytics.

• euromillones.org.es inyecta G-GF0L5TTT4Q desde el payload de Next.js, con un script de consentimiento propio.
• loteriasapi.com y bombolab.es cargan gtag.js directo, con G-8D3P0MXERH y G-WL4JBJ4EX8.
• cuandomevaatocar.com sirve analytics.js con UA-54565716-1, la versión anterior de Google Analytics, retirada en 2023. La etiqueta sigue en el HTML y ya no mide nada.
• Solo bombolab.es declara Consent Mode v2 con analytics_storage denegado por defecto: el script existe, pero no escribe cookies de analítica hasta que el visitante acepta.
• cuandomevaatocar.com entrega además un PHPSESSID a cualquier visitante, también al que solo viene a mirar el resultado.

Ninguna de estas cosas es ilegal por sí sola. Todas juntas describen un sector que trata la consulta de un décimo como una visita más que medir, cuando para el visitante es una de las consultas más personales del año.

Lo que no se ve en la portada

Volvamos a la web de la primera escena, la de la recarga a las 20:07.

Lo que decide si esa web sigue en pie no es la suerte. Es una decisión tomada meses antes, en silencio, por alguien que eligió no depender de una llamada externa en el peor momento posible. Nadie lo verá en la portada. No genera una sola visita.

La suerte no tiene API. Tiene una cadena de personas que decidieron, en algún punto, si el dato se valida o se publica. El 22 de diciembre se ve cuál de las dos cosas hicieron.