¿Qué es una API? Guía sencilla para creadores de apps
Una API (interfaz de programación de aplicaciones) es una forma definida de que un software pida datos a otro o le pida que haga algo. Tu app envía una petición en un formato acordado — «dame las reservas de mañana», «cobra 20 € a esta tarjeta», «resume este texto» — y el otro sistema devuelve una respuesta estructurada. Las API son la forma en que las piezas de una app se comunican entre sí, y cómo tu app usa servicios externos como pagos, correo, mapas e IA.
Por qué importan las API cuando creas con IA
Casi todas las apps útiles están formadas por partes que se comunican mediante API:
- Dentro de tu app, las pantallas del navegador llaman a la API de tu propio backend para cargar y guardar datos.
- Fuera de tu app, tu backend llama a las API de otras empresas: Stripe para cobrar, un proveedor de correo para enviar recibos, un proveedor de modelos de IA para generar texto.
Cuando pides a un constructor con IA que «acepte pagos» o «añada un resumen con IA», lo que realmente hace es escribir código que llama a una API. Conocer lo básico te ayuda a entender qué necesita la IA de ti (normalmente una cuenta en ese servicio y una clave de API), dónde pueden fallar las cosas y cuánto costará.
Una analogía cotidiana
Piensa en un restaurante. No entras en la cocina a cocinar. Lees la carta, le dices al camarero lo que quieres de una forma que la cocina entiende, y el camarero te trae la comida — o te dice que ese plato se ha agotado.
- La carta es la documentación de la API: una lista de lo que puedes pedir y cómo.
- El camarero es la API: la única forma acordada de que las peticiones entren y las respuestas salgan.
- La cocina es el otro sistema: no necesitas saber cómo funciona por dentro.
- Tu pedido es la petición; el plato es la respuesta.
La cocina puede cambiar sus hornos y su personal sin que te afecte, siempre que la carta siga igual. Ese es el verdadero valor de una API: permite que dos sistemas trabajen juntos sin que ninguno necesite saber cómo está construido el otro.
Cómo funciona una petición a una API web
La mayoría de las API que vas a encontrar son API web que funcionan sobre HTTP, el mismo protocolo que usa tu navegador. Cada petición tiene varias partes:
| Parte | Qué es | Ejemplo |
|---|---|---|
| Método | El tipo de acción | GET (leer), POST (crear) |
| URL / endpoint | La dirección de aquello sobre lo que actúas | https://api.example.com/bookings |
| Cabeceras | Información extra, incluido quién eres | Authorization: Bearer <tu clave> |
| Cuerpo | Los datos que envías, para crear o actualizar | {"name": "Lena", "time": "14:00"} |
Y cada respuesta tiene:
| Parte | Qué es | Ejemplo |
|---|---|---|
| Código de estado | Un número que indica cómo ha ido | 200 OK, 201 Creado, 404 No encontrado |
| Cuerpo | Los datos devueltos, normalmente en JSON | {"id": 5001, "status": "confirmed"} |
JSON (JavaScript Object Notation) es un formato de texto sencillo con nombres y valores entre llaves. Es la forma estándar en que las API web intercambian datos.
REST: el estilo más habitual
REST es una convención muy usada para diseñar API web. Cada tipo de cosa tiene su propia URL, y los métodos estándar indican qué le estás haciendo. Así podría ser una API REST para una app de reservas:
| Método | Endpoint | Qué hace |
|---|---|---|
GET | /api/bookings | Listar reservas |
GET | /api/bookings/5001 | Obtener una reserva |
POST | /api/bookings | Crear una reserva nueva |
PATCH | /api/bookings/5001 | Cambiar una parte de una reserva, como su hora |
DELETE | /api/bookings/5001 | Cancelar (borrar) una reserva |
PUT también existe y, por convención, reemplaza un registro completo, mientras que PATCH cambia solo los campos que envías.
Los códigos de estado que verás con más frecuencia:
| Código | Significado |
|---|---|
200 / 201 | Éxito / creado |
400 | Petición incorrecta — algo de lo que enviaste era erróneo o falta |
401 | No autenticado — no hay un inicio de sesión o clave válidos |
403 | Prohibido — te conocen, pero no tienes permiso para esto |
404 | No encontrado |
429 | Demasiadas peticiones — has alcanzado un límite de uso |
500 | El servidor ha tenido un error |
Cuando tu app falla, el código de estado suele ser la pista más rápida. Un 401 de un proveedor de pagos suele significar una clave de API ausente o incorrecta; un 429 significa que llamas con demasiada frecuencia.
REST no es el único estilo — también existen GraphQL y las API de tipo RPC — pero REST es el que usan la mayoría de los servicios y de los backends creados con IA.
Un ejemplo práctico: la confirmación de una reserva
Cuando un cliente reserva un corte de pelo en una app de peluquería, pueden producirse varias llamadas a API en uno o dos segundos:
- La página de reservas del navegador envía
POST /api/bookingscon el servicio, la hora y los datos del cliente a tu backend. - Tu backend comprueba que el hueco está libre, guarda la reserva en la base de datos y devuelve
201 Created. - Tu backend llama a la API de un proveedor de correo con su clave secreta: «envía esta confirmación a lena@example.com».
- Si hay un depósito, tu backend pide a la API del proveedor de pagos que cree una sesión de pago y envía al cliente allí.
- Más tarde, el proveedor de pagos llama a tu app para decir que el pago se ha completado. Esa llamada inversa es un webhook.
Los pasos 1 y 2 son tu propia API entre frontend y backend. Los pasos 3 a 5 son API de terceros.
Términos habituales explicados
| Término | Significado |
|---|---|
| Endpoint | Una URL concreta a la que responde una API. |
| Clave de API | Una cadena secreta que identifica tu app ante un servicio. Trátala como una contraseña. |
| Autenticación | Demostrar quién llama — con una clave, un token o un inicio de sesión. Consulta qué es la autenticación. |
| Límite de uso (rate limit) | Un tope de peticiones que puedes hacer en un periodo. |
| SDK | Una biblioteca de código ya hecha que facilita llamar a una API concreta. |
| Documentación | La «carta»: qué endpoints existen, qué aceptan y qué devuelven. |
| Sandbox / modo de prueba | Una versión de un servicio para probar sin dinero real ni datos reales. |
| Webhook | Una llamada de otro servicio a tu app cuando ocurre algo. |
Errores comunes e ideas equivocadas
- Poner claves secretas en el frontend. Todo lo que está en código que se ejecuta en el navegador puede verlo cualquiera que visite la web. Las claves secretas deben quedarse en el servidor, en variables de entorno o secretos.
- Pegar claves en el chat. El historial del chat puede guardarse. Usa mejor la función de secretos de tu constructor, y renueva cualquier clave que hayas expuesto.
- Dar por hecho que una API es gratuita. Muchas API cobran por petición o por uso — las API de modelos de IA cobran por tokens. Revisa los precios y establece límites de gasto. Consulta cómo usar API de LLM.
- No gestionar los fallos. Los servicios externos caen, agotan el tiempo de espera y alcanzan límites. Pide mensajes de error razonables y reintentos.
- Confiar en el navegador. Tu propia API debe comprobar los permisos por sí misma. Ocultar un botón no impide que alguien llame al endpoint directamente.
- Usar claves reales mientras pruebas. Usa claves de modo de prueba hasta que estés listo para lanzar.
Qué pedir a tu constructor de IA
- «¿Qué API externas usa esta app y cuánto cuesta cada una?»
- «Llama a la API de pagos solo desde el servidor. Lee la clave desde una variable de entorno.»
- «Enumera cada endpoint de nuestra API, qué hace y quién tiene permiso para llamarlo.»
- «Comprueba en el servidor que el usuario con sesión iniciada es el dueño de la reserva antes de actualizarla o borrarla.»
- «Si falla la API de correo, guarda la reserva igualmente y registra el error.»
- «Usa por ahora el modo de prueba del proveedor.»
API en Mythex
Mythex puede construir tu propia API — como parte de una web app o como un backend separado en Node, Python (FastAPI), C# o Java que funciona junto a tu frontend — y escribir el código que llama a servicios externos. Añades sus claves como secretos del proyecto en lugar de en el chat, y están disponibles para tu app en la vista previa y una vez publicada. La documentación tiene recetas para integrar cualquier API y crear un backend de API REST.
Preguntas
¿Qué es una API en pocas palabras?
Una API (interfaz de programación de aplicaciones) es una forma definida para que un software pida datos a otro o le pida que haga algo. Tu app envía una petición en un formato acordado, y el otro sistema devuelve una respuesta — como datos del tiempo, el resultado de un pago o una respuesta generada por IA.
¿Qué es una API REST?
Una API REST es un estilo habitual de API web en el que cada tipo de cosa (reservas, clientes) tiene una URL, y usas métodos HTTP estándar: GET para leer, POST para crear, PUT o PATCH para actualizar y DELETE para borrar. Los datos suelen devolverse en JSON.
¿Qué es una clave de API y dónde debo guardarla?
Una clave de API es una cadena secreta que identifica tu app ante un servicio y que a menudo permite gastar dinero o acceder a datos. Guárdala en variables de entorno o en los secretos de tu proyecto, en el servidor, nunca en código que se ejecute en el navegador ni en un repositorio público.
¿Cuál es la diferencia entre una API y un webhook?
Con una API, tu app pide algo a otro servicio cuando lo necesita. Con un webhook, el otro servicio llama a tu app cuando ocurre algo — por ejemplo, un proveedor de pagos que te avisa de que un pago se ha completado.