¿Qué es una API?

La tecnología invisible del Estado

Cómo funcionan las interfaces que conectan los sistemas del gobierno digital y por qué importan más de lo que parece.

I. El contexto y la pregunta que nadie sabe responder del todo

Las semanas que siguieron al 12 de abril de 2026 fueron raras. Los peruanos acababan de votar para presidente, vicepresidentes, senadores, diputados, parlamento andino y el debate que se instaló en varios medios no fue sobre propuestas ni sobre resultados en sí mismos, sino sobre algo que la mayoría de la gente nunca había tenido que entender: una API.

La pregunta que flotaba en el ambiente, a veces con suspicacia y otras con genuina curiosidad, merecía una respuesta seria: ¿qué es exactamente una API y qué papel juega en un proceso electoral? Para contestarla bien, hay que empezar desde cero, sin atajos.

II. ¿Qué es exactamente una API?

Las siglas vienen del inglés: Application Programming Interface, que se traduce como Interfaz de Programación de Aplicaciones. El nombre intimida, pero la idea que hay detrás es bastante más sencilla de lo que parece.

Una API, en lo esencial, es un conjunto de reglas que permite que dos programas de computadora se comuniquen entre sí. Es el "idioma compartido" que usan los sistemas informáticos para pedirse datos o servicios mutuamente.

Piénsela como la entrada de servicio de un edificio. No es la puerta principal por donde entra el público, sino la lateral por donde acceden los proveedores, los empleados de mantenimiento, los repartidores. Esa entrada define quién puede pasar, por dónde, a qué hora y qué puede llevar consigo.

Cuando uno abre la app del banco en el celular, ve su saldo y sus últimos movimientos. Pero esa pantalla no "tiene" esa información guardada en el teléfono: la pide en tiempo real a los servidores del banco. ¿Cómo? A través de una API.

Otro ejemplo más cercano: si uno entra al portal del RENIEC y solicita una copia certificada de partida de nacimiento, el portal no tiene esos datos. Se los pide a los servidores de RENIEC a través de una API. En cuestión de milisegundos, la respuesta llega y aparece en pantalla. El usuario no ve nada de ese intercambio, pero ocurre cada vez que usa un servicio del Estado. 

Figura 1. Flujo básico de comunicación a través de una API. La API actúa como intermediaria entre quien solicita información y quien la tiene almacenada.

Hay tres palabras en el nombre que vale la pena detenerse a entender:

–       Interfaz: es el punto de contacto entre dos sistemas. Como el mostrador de una ventanilla: el ciudadano interactúa con el mostrador, no directamente con los archivos que están al fondo.

–       Programación: está diseñada para que la usen programas, no personas. Los humanos la construimos y la supervisamos, pero en el día a día son los sistemas los que "hablan" a través de ella.

–       Aplicaciones: conecta programas de software que pueden estar en el mismo servidor o en servidores distintos, incluso en países distintos.

Tres analogías que lo aclaran todo

El mesero del restaurante

Estás en un restaurante y quieres pedir un lomo saltado. No vas directo a la cocina a decírselo al cocinero: eso sería un caos. Llamas al mesero, le das tu pedido, él va a la cocina, transmite la orden, espera que esté lista y te la trae.

–       Tú eres la aplicación que solicita algo: una app de celular, un portal web.

–       El mesero es la API.

–       El cocinero es el servidor con la base de datos.

–       El plato de comida es la información o el servicio solicitado.

El mesero conoce el idioma de la cocina y el idioma del cliente, y traduce entre ambos mundos. Eso es, exactamente, lo que hace una API.

El enchufe eléctrico

Cuando conectas tu refrigeradora al tomacorriente, no necesitas entender cómo funciona la central eléctrica. Solo necesitas que el enchufe tenga el formato correcto. La API es ese estándar de conexión: define el "formato del enchufe" para que cualquier sistema compatible pueda conectarse y recibir lo que necesita, ya sean datos o servicios.

El pasaporte en la frontera

Cuando viajas al exterior, el agente de migraciones no te deja pasar porque se le antoja. Revisa tu pasaporte, verifica que sea válido, que tengas la visa correspondiente, que no figures en ninguna lista de restricción. Solo entonces te permite continuar. Una API opera de la misma manera: cuando un sistema quiere acceder a datos de otro, debe presentar sus credenciales, demostrar que está autorizado y respetar las reglas del sistema receptor. Si algo no cuadra, la solicitud se rechaza.

Una API bien diseñada no solo conecta sistemas. También los protege.

III. Cómo funciona una API por dentro

¿Qué pasa exactamente cuando una API entra en acción? Sigamos el recorrido de una solicitud desde que nace hasta que recibe respuesta.

Paso 1: El cliente hace una solicitud

Todo empieza cuando una aplicación necesita algo. Por ejemplo, el Banco de la Nación quiere verificar si una persona tiene deudas tributarias con SUNAT. Su sistema envía una solicitud a la API de SUNAT. Esa solicitud incluye la dirección del recurso que se quiere consultar (el llamado endpoint), el tipo de operación que se desea realizar, las credenciales de autenticación y los datos adicionales necesarios, como el DNI de la persona.

Paso 2: La API valida la solicitud

Antes de hacer absolutamente nada, la API verifica: ¿quién está pidiendo esto?, ¿tiene permiso?, ¿la solicitud tiene el formato correcto?, ¿no supera los límites establecidos? Este proceso se llama autenticación y autorización, y es la primera línea de defensa del sistema.

Paso 3: La API consulta al servidor

Si todo está en orden, la API traduce la solicitud al lenguaje interno del sistema y la remite al servidor o base de datos correspondiente. Ahí ocurre el trabajo real: el servidor busca la información solicitada.

Paso 4: El servidor responde

El servidor devuelve la información a la API en un formato estándar, generalmente JSON o XML. Son formatos de texto estructurado que los sistemas pueden leer con facilidad. Una respuesta JSON simplificada de la API del RENIEC podría verse así:

{

"status": "200 OK",

 "data": { "nombres": "HEBER IVAN",

 "apellido_paterno": "RAMIREZ",

 "apellido_materno": "LLANOS",

 "fecha_nacimiento": "1985-03-14",

 "estado_civil": "SOLTERO",

 "departamento": "LAMBAYEQUE" },

 "timestamp": "2026-04-12T08:32:45Z"

}

Nada misterioso: es información organizada en un formato que las máquinas pueden leer automáticamente.

Paso 5: La respuesta llega al cliente

La API devuelve la información al sistema que la pidió, que la presenta al usuario de manera legible. Todo este proceso ocurre en milisegundos, habitualmente entre 50 y 500.

Figura 2. Los cinco pasos de una solicitud a través de una API. El ciclo completo toma típicamente menos de medio segundo.

IV. Tipos de API

Así como hay distintas clases de puertas en un edificio, algunas abiertas al público, otras solo para el personal, otras blindadas, existen distintos tipos de API. La clasificación más importante es por nivel de acceso:

–       APIs públicas (Open APIs): cualquier desarrollador puede usarlas, normalmente bajo ciertas condiciones. El ejemplo más conocido es la API de Google Maps. En el ámbito del Estado peruano, la Plataforma Nacional de Datos Abiertos (datosabiertos.gob.pe) expone APIs públicas para acceder a estadísticas gubernamentales sin restricción.

–       APIs privadas (Internal APIs): son de uso exclusivo dentro de una organización. Los sistemas internos del MEF que conectan sus módulos de presupuesto, tesorería y contabilidad, por ejemplo, usan APIs privadas que ningún sistema externo puede consultar.

–       APIs de socios (Partner APIs): se comparten solo con organizaciones que tienen un acuerdo previo. El caso clásico en el gobierno peruano es la Plataforma de Interoperabilidad del Estado (PIDE), administrada por la Secretaría de Gobierno Digital. Las entidades que quieren comunicarse entre sí deben registrarse, firmar acuerdos y recibir credenciales específicas. No es pública, pero tampoco es interna de una sola institución.

–       APIs compuestas (Composite APIs): combinan múltiples consultas en una sola llamada. En lugar de que una aplicación haga tres pedidos por separado, primero a RENIEC, luego a SUNAT, luego a EsSalud, la API compuesta agrupa todo y devuelve la respuesta consolidada. Los sistemas son más eficientes así.

 

Figura 3. Los cuatro tipos de API según su nivel de acceso.

Clasificación por protocolo o arquitectura

Además del nivel de acceso, las APIs también se diferencian por el "idioma técnico" que usan para comunicarse. Las más relevantes en el gobierno digital peruano son estas:

 

 

Tabla 1. Tipos de API según el protocolo que utilizan.

 

V. Las cuatro operaciones básicas: GET, POST, PUT, DELETE

Si las APIs fueran verbos, las cuatro operaciones fundamentales serían: leer, crear, actualizar y eliminar. En el lenguaje técnico de las APIs REST, las más comunes en el gobierno digital, esas acciones tienen nombres precisos, conocidos como operaciones CRUD:

Figura 4. Las cuatro operaciones básicas de una API REST, conocidas colectivamente como CRUD.

Cada operación recibe una respuesta con un código numérico que indica si salió bien o no. Son como los semáforos del tráfico de datos:

Código	Significado	Analogía cotidiana
200 OK	Todo salió bien.	Luz verde.
201 Created	Se creó un nuevo registro.	Recibo de confirmación.
400 Bad Request	La solicitud estaba mal formada.	Formulario llenado con errores.
401 Unauthorized	No tiene credenciales válidas.	El portero no lo deja pasar.
403 Forbidden	Credenciales válidas, pero sin permiso para ese recurso.	Empleado sin acceso al piso VIP.
404 Not Found	El recurso solicitado no existe.	Número de teléfono equivocado.
429 Too Many Requests	Demasiadas solicitudes en muy poco tiempo.	Seguridad que detiene un acceso masivo.
500 Server Error	Falla interna del servidor.	La cocina del restaurante, en llamas.

Tabla 2. Códigos de respuesta de una API y su significado práctico.

Estos códigos son herramientas de diagnóstico. Si durante una consulta se reciben errores 500, el problema está en los servidores, no en la conexión a internet del usuario. Si aparecen errores 401 o 403, hay un problema de autenticación o de permisos.

VI. Seguridad en las APIs: llaves, candados y guardianes

La seguridad es el aspecto más crítico de una API, sobre todo cuando maneja datos sensibles. Los sistemas bien diseñados implementan varias capas de protección:

–       API Keys: el mecanismo más básico. Un sistema que quiere usar la API recibe una clave secreta, una cadena de letras y números, que debe incluir en cada solicitud. Si alguien obtiene esa clave sin autorización, puede hacer solicitudes haciéndose pasar por el sistema legítimo.

–       OAuth 2.0 y tokens de acceso: el estándar moderno. En lugar de una contraseña fija, el sistema recibe un token temporal que expira pasado cierto tiempo. Es como un pase de visitante: válido hoy, inútil mañana. El Reglamento de la Ley de Gobierno Digital del Perú (DS 029-2021-PCM) establece que se pueden utilizar estándares internacionales para la plataforma ID GOB.PE.

–       HTTPS y cifrado TLS: todas las comunicaciones deben ir encriptadas. El HTTPS es el candadito que uno ve en el navegador: garantiza que, aunque alguien intercepte la comunicación, no pueda leer nada. Como enviar una carta en un sobre que solo el destinatario puede abrir.

–       Límite de velocidad (rate limiting): las APIs bien diseñadas limitan cuántas solicitudes puede hacer un sistema en un período de tiempo. Si alguien intenta lanzar 10.000 peticiones por segundo, el sistema las bloquea automáticamente. Esto protege contra ataques de fuerza bruta y de denegación de servicio.

–       Lista blanca de IPs (IP whitelist): algunos sistemas solo aceptan conexiones desde direcciones IP conocidas. Aunque un atacante tuviera la clave de acceso, si no figura en la lista de IPs autorizadas, la solicitud se rechaza. Es como un edificio que, además de pedir contraseña, verifica que la llamada viene de un número conocido.

–       Logs y auditoría: toda acción debe quedar registrada. Cada solicitud a una API debería dejar rastro: quién la hizo, cuándo, desde dónde, qué pidió y qué respuesta recibió. Esos registros son la herramienta principal para detectar accesos no autorizados o comportamientos anómalos.

 Figura 5. Capas de seguridad en una API bien diseñada. Un atacante tendría que superar cada una de ellas para llegar a los datos.

La seguridad de una API no es un interruptor que se enciende y se apaga. Es un sistema de capas en el que cada una protege a la siguiente: si una falla, las demás deben contener la amenaza.

VII. ¿Puede una API ser "hackeada"?

La respuesta corta es sí. Pero el "cómo" y el "con qué consecuencias" son bastante más complejos que una respuesta de dos letras. Estas son las vulnerabilidades más documentadas:

Inyección (Injection)

Un atacante envía datos maliciosos que el sistema interpreta como instrucciones. El ejemplo clásico es la inyección SQL: en lugar de enviar un DNI legítimo, el atacante manda un código que le ordena a la base de datos "dame todos los registros" o "borra esta tabla". Una API bien construida valida y limpia todos los datos que recibe, rechazando cualquier cosa que no tenga el formato esperado.

La analogía: imagínese que llama a un restaurante para pedir delivery. En vez de pedir "un lomo saltado", dice: "ignora mi pedido anterior y dame las direcciones de todos tus clientes". Un sistema bien entrenado, un buen mesero, reconoce que eso no es un pedido de comida y lo rechaza sin más.

Autenticación rota (Broken Authentication)

Ocurre cuando el sistema de verificación de identidad tiene grietas: tokens que nunca expiran, contraseñas débiles, ausencia de autenticación en dos pasos. Un atacante que consiga un token válido puede hacer solicitudes como si fuera un sistema autorizado. La defensa es aplicar estándares modernos como OAuth 2.0 con tokens de corta duración.

Exposición excesiva de datos

Una API devuelve más información de la necesaria. Si una app de consulta electoral llama a la API y recibe no solo los resultados sino también datos internos de configuración del sistema, esa información adicional puede ser aprovechada por un atacante. El principio de "mínimo privilegio" establece que cada solicitud debe recibir únicamente lo que es estrictamente necesario para responderla.

Autorización a nivel de objeto defectuosa (BOLA)

Una de las vulnerabilidades más comunes y peligrosas. Ocurre cuando un usuario autorizado puede acceder a datos de otros usuarios simplemente cambiando un número en la solicitud. Si la API responde correctamente a: /persona/90074588/resultados, pero también responde sin verificación a: /persona/99999999/resultados, —de alguien a quien no debería tener acceso—, hay un problema grave. En sistemas críticos, eso podría permitir leer información no autorizada.

Denegación de servicio (DDoS)

Un atacante lanza millones de solicitudes simultáneas para saturar los servidores y dejar el sistema inaccesible. No manipula datos: los bloquea. Es la diferencia entre robar el contenido de una caja fuerte y simplemente tapar la puerta del banco para que nadie entre. El clásico: "si no es para mí, que no sea para nadie".

Ataque de hombre en el medio (MITM)

Un tercero se interpone entre el usuario y el servidor, interceptando y potencialmente modificando los datos en tránsito. La principal defensa es el cifrado HTTPS/TLS: aunque alguien capture la comunicación, no puede leerla ni alterarla sin que el sistema lo detecte.

 Figura 6. Vulnerabilidades comunes en APIs y sus mecanismos de defensa.

Cuando se sospecha de una vulneración, la auditoría técnica debería revisar al menos los siguientes elementos:

–       Logs de acceso: ¿quién accedió a cada API, cuándo, desde qué IP y con qué credenciales?

–       Integridad de datos: ¿los datos en los servidores coinciden con los hash criptográficos generados al momento de la transmisión?

–       Verificación cruzada: ¿los datos de los documentos físicos coinciden con los registrados en el sistema?

–       Revisión del código fuente: ¿el software tiene vulnerabilidades conocidas?, ¿fue sometido a pruebas de penetración (pentesting) antes de su despliegue?

–       Arquitectura: ¿los sistemas tenían la debida separación de privilegios?, ¿existía un API Gateway con los controles adecuados?

Conclusiones

Las APIs están lejos de ser un concepto reservado a especialistas. Son, en términos prácticos, el tejido invisible que articula el funcionamiento del Estado digital: el mecanismo que permite que sistemas distintos, desarrollados en épocas distintas, por instituciones distintas, con tecnologías distintas, puedan intercambiar información de manera eficiente, segura y controlada.

Una de sus virtudes principales es que separan la experiencia del usuario de la complejidad interna de los sistemas. El ciudadano interactúa con interfaces simples, apps, portales web, sin necesidad de entender la infraestructura que hay detrás. Esa abstracción no solo mejora la experiencia: también permite que el Estado evolucione tecnológicamente sin afectar al usuario final. La API actúa como intermediaria estable que garantiza continuidad en el servicio, incluso cuando los sistemas internos cambian.

Las APIs funcionan porque establecen reglas claras: cómo pedir información, en qué formato recibirla y bajo qué condiciones acceder a ella. Esa estandarización reduce la ambigüedad, facilita la integración entre entidades y acelera el desarrollo de nuevos servicios digitales. En un país con múltiples instituciones públicas, esa capacidad de integración resulta esencial para avanzar hacia un gobierno digital genuinamente interoperable.

Al mismo tiempo, las APIs no son invulnerables. Las amenazas conocidas, inyecciones, fallas de autenticación, ataques de denegación de servicio, obligan a adoptar un enfoque de seguridad en capas donde la prevención, el monitoreo y la auditoría son permanentes. La seguridad no es un estado que se alcanza una vez: es un proceso continuo.

La clasificación de las APIs según su nivel de acceso, públicas, privadas, de socios y compuestas, refleja cómo se gestiona la información en distintos niveles de apertura. En el Estado, eso cobra especial relevancia porque equilibra dos necesidades que a veces parecen contradictorias: la transparencia y la protección de datos sensibles. Plataformas como datosabiertos.gob.pe promueven el acceso libre a la información pública, mientras que sistemas como la PIDE garantizan intercambios seguros entre entidades gubernamentales.

La tecnología, incluidas las APIs, no es buena ni mala por naturaleza: es una herramienta. Una API bien diseñada, con controles de seguridad adecuados, auditoría constante y transparencia en su funcionamiento, puede fortalecer a las instituciones del Estado. Una API mal implementada, sin auditoría ni transparencia, puede convertirse en un punto de falla que erosione la confianza pública. Y esa confianza no se gana solo con afirmar que los sistemas son seguros: se gana demostrándolo, con logs preservados, auditorías independientes y disposición real a rendir cuentas.