API: qué es y cómo conecta aplicaciones

Una API —Application Programming Interface— es la pieza de software que permite que dos aplicaciones se entiendan. Cuando reservas un vuelo y la aerolínea consulta disponibilidad de hoteles para ofrecerte un paquete, una API conecta ambos sistemas. Cuando tu CRM se actualiza al recibir un nuevo lead desde tu web, una API empuja los datos. Cuando pides a una herramienta de IA que resuma un documento, una API transmite tu petición al modelo y devuelve la respuesta.

Las APIs son invisibles para el usuario final. Pero el internet moderno funciona sobre APIs: cada aplicación con cada otra, cada servicio en la nube exponiendo capacidades, cada empresa abriendo su sistema a integraciones que multiplican su valor. Entender qué es una API —y especialmente, qué decisiones implican integrar una— es indispensable para cualquier equipo que opere productos digitales o automatice procesos.

Este artículo explica qué es exactamente una API, cómo evolucionó hasta el modelo actual, los tipos principales que conviene conocer (REST, GraphQL, webhooks), los ejemplos canónicos que hoy son referencia (Stripe, Twilio, OpenAI), y los errores que repiten equipos al integrar.

Qué es exactamente

Una API es un contrato entre dos sistemas: las reglas con las que un programa puede pedirle a otro información o acciones, y las reglas con las que el otro responde.

Un ejemplo concreto: imagina un servicio que entrega el precio actual del bitcoin. Sin API, tendrías que abrir su web, leer el número y copiarlo. Con API, tu programa hace una petición específica (algo como "GET /v1/prices/BTC"), el servicio devuelve una respuesta estructurada (típicamente JSON: {"price": 65432, "currency": "USD", "timestamp": "2026-05-05T12:00:00Z"}), y tu programa puede usarla automáticamente.

Las APIs definen:

• Qué se puede pedir (endpoints, métodos, parámetros).
• Cómo se debe pedir (formato, autenticación, headers).
• Qué se devuelve (formato de respuesta, códigos de estado, errores).
• Qué límites hay (rate limiting, cuotas, planes de pago).
• Qué reglas de seguridad aplican.

Un equipo que integra una API ajena no necesita entender cómo está hecha por dentro; solo necesita entender el contrato. Y un equipo que ofrece una API debe documentarla con la disciplina con la que se documenta un contrato legal: las ambigüedades cuestan tiempo, dinero y confianza.

El recorrido histórico que conviene conocer

El concepto de "interfaz para que un programa hable con otro" es tan antiguo como la programación. Lo que ha cambiado es cómo y a qué escala.

Años 60-70: APIs como bibliotecas de subrutinas. El término empezó a aparecer en literatura técnica de IBM y otros fabricantes en los años 60. Las APIs eran librerías de funciones que un programador llamaba desde su código —pensemos en bibliotecas matemáticas, de gestión de archivos, de sistema operativo. Vivían dentro de la misma máquina.

Años 80-90: APIs en sistemas distribuidos. Con la red, surgieron protocolos como CORBA (1991) y DCOM (Microsoft, 1996) para que aplicaciones en máquinas distintas se llamaran entre sí. Eran complejos, pesados, frágiles —pero abrieron la puerta.

1998-2000: la web empieza a ser API. SOAP (Simple Object Access Protocol, 1998) trajo un protocolo basado en XML para servicios web. Salesforce lanzó su API en febrero de 2000, una decisión que se considera fundacional —fue una de las primeras grandes empresas SaaS en exponer su funcionalidad para que terceros construyeran sobre ella—. eBay lanzó su API el mismo año. Amazon abrió su Product Advertising API en julio de 2002 (otra decisión que cambió el ecosistema).

2000: REST. Roy Fielding, en su tesis doctoral en UC Irvine, Architectural Styles and the Design of Network-based Software Architectures (junio de 2000), formalizó REST (Representational State Transfer). REST se convirtió en el estilo arquitectónico dominante para APIs web por su simplicidad: usaba el protocolo HTTP que ya existía, identificaba recursos con URLs limpias, y dejaba que los desarrolladores trabajasen con JSON o XML según conviniera.

2004-2007: la era de las APIs públicas. Flickr abrió su API en 2004, Twitter en 2006, Facebook Platform en 2007. La idea de "construir sobre los datos de otros" pasó de novedad a estándar. Apareció el directorio ProgrammableWeb (2005), que catalogaba miles de APIs públicas.

2008-2010: las APIs como producto. Twilio se fundó en 2008 y popularizó la idea de "API as a product": vender la integración como producto principal, sin interfaz de usuario para humanos. Stripe, fundada en 2010 por los hermanos Patrick y John Collison, llevó esa idea a otro nivel con una API que se consideraba un objeto de admiración técnica. Stripe se convirtió en referencia: documentación impecable, errores claros, ergonomía obsesiva. Cualquier equipo que diseña una API moderna mira a Stripe.

2012-2015: el rediseño de la conversación. Facebook publicó GraphQL internamente en 2012 y lo abrió en 2015. GraphQL respondía a un problema real de las APIs REST: el cliente recibe lo que el servidor decide, no lo que el cliente necesita —lo que produce respuestas o demasiado grandes (over-fetching) o múltiples llamadas (under-fetching). Con GraphQL, el cliente declara exactamente qué datos quiere y el servidor responde con esa forma. Es popular en aplicaciones complejas con muchas pantallas y datos relacionados.

2015: gRPC. Google publicó gRPC, un framework de RPC moderno basado en HTTP/2 y Protocol Buffers. Funciona mejor que REST para comunicación entre servicios internos donde la performance importa.

2017-2020: APIs como infraestructura básica. Postman (cliente para probar APIs) llega a ser estándar, OpenAPI/Swagger se consolida como formato de documentación, surge una industria entera de API gateways (Kong, Apigee, AWS API Gateway), monitorización (Datadog, New Relic) y testing.

2022-2026: las APIs de IA. Con el lanzamiento de GPT-3 (junio 2020), ChatGPT (noviembre 2022), Claude (Anthropic, marzo 2023), Gemini (Google, diciembre 2023), las APIs se vuelven la interfaz principal para acceder a modelos de IA generativa. La conversación cambia: ahora una API no solo entrega datos —puede generar texto, imagen, código, decisiones. Las APIs de OpenAI, Anthropic y similares se convierten en piezas centrales de software moderno, con sus propias particularidades (latencia variable, costes por token, gestión de contexto).

Tipos de APIs que conviene conocer

REST sigue siendo el más común. Una API REST expone "recursos" (usuarios, productos, pedidos) con URLs claras, y se manipulan con verbos HTTP (GET para leer, POST para crear, PUT/PATCH para actualizar, DELETE para borrar). La mayoría de APIs públicas que encuentras hoy son REST.

GraphQL se usa cuando la flexibilidad del cliente importa: aplicaciones con muchas vistas distintas, dashboards, apps móviles donde minimizar transferencia importa.

gRPC se usa entre servicios internos en arquitecturas modernas (microservicios) donde la velocidad y la tipificación estricta valen más que la facilidad de inspección.

SOAP sobrevive en empresas con integraciones legacy —banca, aseguradoras, administraciones públicas. Si trabajas en sectores tradicionales, lo encontrarás.

Webhooks son inversos: en lugar de tu sistema preguntar al otro, el otro te avisa cuando algo ocurre. El término lo acuñó Jeff Lindsay alrededor de 2007. Stripe te notifica cuando un pago se completa; Slack notifica cuando alguien envía un mensaje a un canal. Más eficiente que estar preguntando, y más en tiempo real.

APIs de streaming (WebSockets, Server-Sent Events) abren conexiones permanentes para flujos de datos continuos: cotizaciones bursátiles, chat en tiempo real, actualizaciones de geolocalización.

APIs de IA / LLMs: técnicamente son REST, pero con particularidades. Reciben texto y devuelven texto generado; cobran por tokens (unidades de texto procesado); pueden tardar segundos por respuesta; soportan streaming de la respuesta a medida que se genera.

Autenticación: cómo se controla quién accede

Casi ninguna API real es completamente abierta. Algún tipo de credencial controla acceso.

API key: un token único asignado a cada cliente. Sencillo, ampliamente usado para APIs públicas no críticas.

Basic auth: usuario y contraseña en cada petición. Simple pero limitado.

OAuth 2.0 (estándar IETF de 2012, RFC 6749): el protocolo dominante para autenticación delegada. Es lo que ocurre cuando una app pide "permiso para acceder a tu Google Calendar" sin pedir tu contraseña: te redirige a Google, autorizas, y la app recibe un token con permisos específicos.

JWT (JSON Web Tokens): tokens firmados criptográficamente que contienen información del usuario. Muy usados en APIs modernas.

mTLS (mutual TLS): autenticación mediante certificados, para APIs entre máquinas en contextos de alta seguridad.

La elección depende del riesgo del recurso expuesto y del tipo de cliente. Para APIs internas, JWT o API key. Para acceso de terceros a datos de usuario, OAuth 2.0. Para banca y datos sensibles, mTLS y autenticación adicional.

Ejemplos canónicos: las APIs que se admiran

Stripe: probablemente la API más alabada en la industria. Endpoints claros, documentación impecable, mensajes de error precisos, herramientas de testing, idempotencia bien resuelta (puedes reintentar una petición sin crear duplicados). Cualquier equipo que diseña una API estudia Stripe.

Twilio: API para envío de SMS, voz, vídeo. Pionero del modelo "API como producto principal." Documentación con ejemplos en múltiples lenguajes.

Slack API: ejemplos de webhooks, OAuth bien implementado, documentación interactiva.

OpenAI / Anthropic: APIs de modelos de IA. Diseño relativamente simple para la complejidad del servicio que entregan. Streaming de tokens. Manejo de cuotas y costes integrado.

Mapbox / Google Maps: APIs de mapas y geolocalización. Casos de uso desde simple visualización hasta routing complejo.

Mailgun / SendGrid / Postmark: APIs para envío transaccional de email.

Estudiar la documentación de estas APIs antes de diseñar una propia o evaluar otras es uno de los mejores ejercicios para un equipo técnico.

Casos típicos de integración en un equipo de marketing

No solo desarrolladores integran APIs. Equipos de marketing las usan, directamente o vía herramientas no-code, para:

• Sincronizar leads entre formulario web y CRM (HubSpot, Salesforce, Pipedrive).
• Enviar email transaccional (Mailgun, Postmark, SendGrid).
• Obtener métricas de redes sociales (Meta Graph API, X API, LinkedIn API).
• Publicar contenido programado en redes sociales.
• Procesar pagos en e-commerce (Stripe, PayPal, Adyen).
• Verificar emails o enriquecer datos (Clearbit, Apollo, ZeroBounce).
• Conectar herramientas mediante automatización (Zapier, Make, n8n) que orquesta APIs sin código.
• Acceder a IA generativa para producción de contenido o transcripción.

Las plataformas de iPaaS (Integration Platform as a Service) —Zapier desde 2011, Make (antes Integromat) desde 2012, n8n más reciente— democratizaron el uso de APIs sin necesidad de programar, permitiendo a equipos no técnicos diseñar flujos automatizados.

Decisiones operativas antes de integrar una API

Cinco preguntas críticas antes de invertir tiempo en una integración:

¿Cumple los términos de uso? Algunas APIs prohíben usos comerciales, scraping de contenido, o requieren ofrecimientos específicos. Leer los TOS antes de construir sobre ellos evita rebuilds forzados.

¿Qué pasa cuando falla? Toda API falla. Lo que importa es cómo. ¿Tu integración degrada con elegancia (graceful degradation) o se cae completa? ¿Hay reintentos automáticos? ¿Hay alertas?

¿Qué cuesta a escala? Las APIs comerciales suelen cobrar por volumen. Una integración que en pruebas cuesta 10 €/mes puede costar 10.000 €/mes en producción. Leer pricing y simular escenarios.

¿Cumple regulación? GDPR/RGPD, HIPAA si es salud, PCI-DSS si maneja tarjetas. La API puede ser perfecta técnicamente y descalificarte legalmente si los datos terminan donde no deben.

¿Qué pasa si la API cambia o desaparece? Las APIs cambian. Empresas se compran, productos se discontinúan. Una integración profunda con una API frágil es deuda técnica. ¿Tienes plan B?

Errores que se repiten en cada integración

No leer la documentación. El error más caro y común. La documentación de las APIs serias contiene los detalles que evitan problemas: limites, rate limits, idempotencia, errores específicos.

Hardcodear la API key en el código. Las credenciales pertenecen a variables de entorno o gestores de secretos (AWS Secrets Manager, HashiCorp Vault, Doppler), nunca al repositorio de código. Una API key filtrada en GitHub puede costar miles antes de detectarla.

No manejar errores. Asumir que la API siempre responde correctamente y construir sin try/catch ni reintentos. La primera vez que el servicio cae, la integración se rompe.

Ignorar el rate limiting. Hacer 10.000 peticiones por minuto a una API que permite 60 acaba con tu IP bloqueada y, según los TOS, con tu cuenta suspendida.

No verificar webhooks. Webhooks que llegan sin verificación criptográfica son vector de ataque: cualquiera puede enviar peticiones falsas. Verificar la firma siempre.

Logs con datos sensibles. Logs útiles para debug que terminan registrando contraseñas, tokens o datos personales. Los logs son la fuente más común de fuga de credenciales.

No versionar la integración. Las APIs evolucionan. Construir contra "la última versión" sin pinning produce ruptura sorpresa cuando la API cambia. Las APIs serias tienen versionado (v1, v2) y dan tiempo de migración; aprovecharlo.

Acoplamiento excesivo. Construir tu producto pegado a una API específica de manera que cambiar es imposible. Una capa de abstracción mínima protege ante cambios o cambios de proveedor.

Sincronización ingenua. Sincronizaciones bidireccionales mal diseñadas producen bucles infinitos, conflictos, datos duplicados. Las direcciones de verdad y las reglas de resolución de conflictos hay que decidirlas explícitamente.

No documentar internamente. Una integración que solo entiende quien la construyó se vuelve frágil cuando esa persona se va. Documentar qué API, con qué credenciales, qué hace, qué fallos vigilar.

Cómo encajar las APIs en operaciones creativas

El uso de APIs en operaciones creativas se ha multiplicado: gestión de assets, publicación automática, transcripciones de IA, métricas centralizadas, sincronización entre herramientas. Sin sistema, cada integración es decisión local sin documentación, y se acumula deuda invisible.

Operaciones creativas son lo que ordena ese caos. En Polimake, Studio define qué herramientas se usan y cómo se integran (qué API conecta con qué); Studio coordina los flujos automatizados (publicación, aprobaciones, notificaciones); Media ejecuta integraciones específicas de assets (DAM, transcripción, exportación a canales).

Esto se relaciona con la decisión de hosting sobre el que vive cada integración, con la elección de CMS que suele ofrecer su propia API, y con la práctica más amplia de automatización.

Para cerrar

Las APIs son la infraestructura silenciosa del software moderno. Cada herramienta que usas en marketing, cada plataforma de publicación, cada sistema de pago, cada modelo de IA accesible —todo se sostiene en APIs. Entenderlas no es opcional para quien gestiona productos digitales o automatiza procesos: es alfabetización básica.

La práctica que mejor envejece: tratar cada integración como inversión que requiere documentación, monitorización y mantenimiento, no como atajo "que ya funciona." Una integración bien diseñada se mantiene años; una improvisada se rompe en seis meses y deja a alguien apagando incendios un viernes por la tarde.

Referencias rápidas

• API = contrato entre dos sistemas. Define qué se pide, cómo y qué se devuelve.
• REST sigue siendo el estándar dominante. GraphQL cuando hay que minimizar transferencia. gRPC entre servicios internos.
• Webhooks invierten la dirección: el servidor te avisa cuando algo ocurre.
• OAuth 2.0 para acceso delegado a datos de usuarios. API key para casos simples.
• Stripe, Twilio, OpenAI: ejemplos canónicos a estudiar.
• iPaaS (Zapier, Make, n8n) democratiza APIs sin código.
• Antes de integrar: TOS, gestión de fallos, coste a escala, regulación, plan B.
• Nunca hardcodear credenciales. Variables de entorno o secret manager.
• Manejar errores y rate limits desde el primer día.
• Verificar firmas de webhooks.
• Versionado y abstracción para que cambios futuros no rompan tu producto.
• Documentación interna es parte de la integración, no algo aparte.