bdns-subvenciones

Actor de Apify que lee la API oficial y abierta de la Base de Datos Nacional de Subvenciones (BDNS) española y devuelve, por cada convocatoria: título, órgano convocante, importe, sector (código CNAE), región, finalidad, plazos y enlace a la ficha pública.

Segundo actor construido con la misma plantilla que ../placsp-licitaciones: la separación bdnsClient.js (red + paginación) / parser.js (normalización) / main.js (orquestación + Apify SDK) es el mismo patrón, reutilizado.

Por qué este dataset

• API REST pública, JSON, sin autenticación — mantenida por la IGAE (Intervención General de la Administración del Estado). Sin anti-bot, sin captchas, sin necesidad de proxy.
• Sin datos personales: las convocatorias son de organismos públicos y personas jurídicas, no de personas físicas beneficiarias.
• Sin competencia detectada en Apify Store en el momento de construirlo.
• Mismo comprador que el actor 1 (PLACSP): consultoras, gestorías, constructoras e ingenierías que ya monitorizan licitaciones también monitorizan subvenciones — venta cruzada natural a la misma cartera de clientes potenciales.
• Filtro por sector real: el campo sectores[].codigo de la API es un código tipo CNAE, así que el input soporta cnaePrefijos igual que placsp-licitaciones soporta cpvPrefijos.

Estado actual (2026-08-11)

• ✅ API investigada y verificada con peticiones reales (no solo documentación): endpoints de listado (/convocatorias/busqueda) y detalle (/convocatorias?numConv=X&vpd=GE) confirmados, con ejemplo real de respuesta capturado (ver test/sample-detalle.json, basado en la convocatoria BDNS 924629, Principado de Asturias).
• ✅ Patrón de URL pública para el campo enlace verificado navegando a la ficha real: https://www.infosubvenciones.es/bdnstrans/GE/es/convocatorias/{codigoBDNS}.
• ✅ Cliente, parser y orquestación implementados y probados (npm test, 6/6 OK) contra fixtures con datos reales capturados, incluyendo un caso con campos opcionales ausentes.
• ⏳ Pendiente de desplegar y probar con runs reales en Apify (mismo motivo que en el actor 1: este entorno de desarrollo en la nube no tiene salida de red a infosubvenciones.es, solo a un puñado de dominios permitidos — node src/main.js aquí falla con HTTP 403, que es el bloqueo del sandbox, no necesariamente de BDNS. Hay que confirmarlo en Apify real, igual que se hizo con PLACSP).
• ⏳ Pendiente: ficha de tienda (STORE_LISTING.md) y precio — a fijar con datos reales de volumen del primer run, como se hizo con PLACSP.

Estructura del proyecto

.actor/actor.json        Metadatos del actor para Apify
.actor/input_schema.json Formulario de input (fecha, filtro CNAE, límites)
Dockerfile                Imagen del actor (apify/actor-node:20)
src/config.js              Constantes de la API BDNS (URL base, cabeceras, concurrencia)
src/bdnsClient.js           Listado (con paginación) + detalle de convocatorias
src/parser.js                Normalización del JSON crudo -> esquema de salida
src/main.js                   Orquestación: input -> listado del día -> detalle -> dataset + monitor
test/parser.test.js           Tests con fixtures de datos reales capturados (npm test)
test/sample-detalle.json      Fixture: convocatoria real (BDNS 924629)
test/sample-detalle-minimo.json  Fixture: caso con campos opcionales ausentes

Campos que devuelve cada convocatoria

codigoBDNS, titulo, organo (ambito, entidad, departamento), importe.presupuestoTotal, instrumentos (tipo de ayuda), tiposBeneficiarios, sectores (array de {codigo, descripcion}, tipo CNAE), regiones (array de descripciones NUTS), finalidad, basesReguladoras (titulo, url), sePublicaDiarioOficial, abierto, plazo (fechaInicioSolicitud, fechaFinSolicitud), mecanismoRecuperacionResiliencia (fondos Next Generation), fechaRecepcion, enlace.

Cómo probarlo

npm install
npm test              # tests del parser contra datos reales capturados
node src/main.js      # ejecución completa (necesita salida a internet real)

node src/main.js en este entorno de desarrollo en la nube fallará con HTTP 403 — es la lista blanca de salida de red de este entorno, no necesariamente un bloqueo real de BDNS (ver "Estado actual" arriba). Pruébalo desde tu propio ordenador o, mejor, directamente en Apify.

Input

Ver .actor/input_schema.json. Por defecto: fecha de hoy (Europe/Madrid), sin filtro de sector CNAE, hasta 50 páginas de 100 resultados cada una.

Riesgo conocido / a vigilar

• La API no documenta un rate limit numérico, solo advierte de que puede restringir el acceso ante "abuso manifiesto del servicio" (texto embebido en las propias respuestas). El cliente ya throttlea las peticiones de detalle (concurrencia limitada + pausa entre lotes, ver src/config.js) — vigilar si esto es suficiente con volumen real.
• El volumen diario real (~400 convocatorias/día a nivel nacional el 2026-08-11, verificado) implica ~400 peticiones de detalle por run sin filtro — bastantes más peticiones por run que PLACSP. Repetir el mismo ejercicio que se hizo con PLACSP: correr sin filtro para ver el volumen y coste real, y con 1-2 cnaePrefijos para dimensionar el caso de uso por sector antes de fijar precio.

Siguientes pasos (en orden)

1. Desplegar este actor en Apify (Web IDE, igual que PLACSP) y lanzar un run de prueba real sin filtro, para confirmar que no hay bloqueo y ver el volumen/coste real.
2. Repetir con 1-2 cnaePrefijos representativos (p. ej. ["62"] programación informática, ["41"] construcción) para calibrar el precio por sector.
3. Escribir STORE_LISTING.md con los datos reales de volumen (mismo patrón que PLACSP: no vender "toda España cada día" si el volumen nacional es demasiado alto para el precio por ítem).
4. Configurar monetización pay-per-event, publicar en la Store.
5. Reutilizar el mismo repo de monitorización (placsp-licitaciones-monitor) o crear uno nuevo análogo para este actor.