Conectar servicios: emails, pago, IA

La app que habla con el mundo

El éxito de la app de Tom supera su clase: una colega de lengua la usa con sus alumnos de 2.º de ESO, y un profe de mates de otro instituto le ha escrito para saber «cómo instalarla para su centro — y cuánto cuesta». Emergen tres deseos: enviar a los alumnos un resumen semanal por email, añadir un mensaje de ánimo generado por IA cuando un alumno termina su día, y proponer una versión «clase» de pago para los profes de otros institutos. Tres funcionalidades, un mismo mecanismo: hacer dialogar su app con servicios externos.

Ese diálogo pasa por las API (interfaces de programación). El principio: un servicio — Resend para los emails, Stripe para el pago, Claude para la IA — expone una ventanilla en Internet. Tu app se presenta ahí con una petición estructurada («envía este email a esta dirección») y una clave API que prueba su identidad, y el servicio ejecuta y responde. No necesitas entender cómo Resend encamina un email, igual que no necesitas entender una central eléctrica para enchufar un aparato: la API es el enchufe.

La regla de oro: las claves se quedan en el servidor

Antes de la más mínima conexión, una regla absoluta. Tu clave API es una tarjeta bancaria: quien la posea consume el servicio en tu nombre y a tu costa. Y todo el código que corre en un navegador es legible por cualquiera — basta un simple F12. Conclusión implacable: una clave secreta no debe encontrarse nunca en el código del lado navegador. Vive en el lado servidor, ahí donde nadie puede leerla.

«¡Pero si yo no tengo servidor!» Sí, casi: Vercel (y sus competidores) propone funciones servidor — pequeños trozos de código alojados en su infraestructura, que se ejecutan bajo demanda. El esquema es siempre el mismo: el navegador llama a tu función servidor (sin clave), la función llama al servicio externo (con la clave, almacenada en una variable de entorno), y devuelve al navegador únicamente el resultado. La IA sabe crear estas funciones perfectamente — tu trabajo es exigir esta arquitectura en tus prompts.

flowchart LR
  N["Navegador del alumno"] -->|"Petición sin ninguna clave"| F["Función servidor en Vercel"]
  F -->|"Llamada con la clave secreta"| S["Servicio externo: Resend, Stripe o Claude"]
  S -->|"Respuesta"| F
  F -->|"Resultado limpio"| N

Enviar emails: el resumen semanal

Primera conexión: el email. No se envían emails automáticos desde tu buzón de Gmail — los proveedores lo bloquean rápido y es frágil. Se pasa por un servicio de email transaccional como Resend, Postmark o Brevo: diseñados para apps, fiables, y gratuitos a pequeña escala (Resend ofrece 100 emails al día, muy por encima de las necesidades de Tom). El prompt de Tom, completo:

Añade el envío de un email recapitulativo a mi app de seguimiento de hábitos.
Contexto: app HTML/JS en Vercel, datos en Supabase, autenticación por enlace mágico.
Lo que quiero:
1. un botón «recibir mi resumen de la semana» en la página principal
2. al hacer clic, una función servidor de Vercel calcula las rachas y las marcas de la semana del usuario conectado, y le envía un email limpio y legible vía Resend
3. la clave API de Resend se queda en el lado servidor, en una variable de entorno de Vercel — nunca en el código del navegador
4. límite estricto: un envío por usuario y por día como máximo, con un mensaje claro si se alcanza el límite
Guíame primero para crear la cuenta de Resend y configurar la variable de entorno en Vercel, y después programa la función.
Una etapa a la vez, espero a probar antes de la siguiente.

Detente en la línea 4: «un envío por usuario y por día». ¿Por qué limitar una funcionalidad gratuita? Porque todo botón que activa un servicio externo puede ser martilleado — por un alumno bromista o por un robot — y cada envío consume tu cuota. Poner un límite desde el diseño es un reflejo de arquitecto: proteges tu servicio antes de que lo necesite. Generalizaremos este reflejo en el capítulo 9.

Cobrar un pago sin programar: Stripe Payment Links

Para la versión «clase» de pago, Tom teme lo peor: el pago en línea es serio, regulado, ansiógeno. Buena sorpresa: Stripe, el servicio de pago más usado por los desarrolladores, propone los Payment Links — páginas de pago alojadas por Stripe, creadas en unos clics en su panel, sin una línea de código. Creas un producto («Versión clase — 29 €/año»), Stripe genera una URL, y tu app solo tiene que mostrar un botón que apunte a esa URL. Stripe gestiona la tarjeta bancaria, la seguridad, la facturación, los reembolsos.

• Crea una cuenta en stripe.com y quédate en modo test por ahora.
• En el panel: Productos → añadir «Versión clase» con su precio.
• Genera el Payment Link del producto y copia la URL.
• Pide a la IA que añada una página «versión clase» con los beneficios y un botón hacia ese enlace.
• Prueba el recorrido completo en modo test, y activa el modo real cuando todo esté validado.

Los Payment Links tienen límites — no hay desbloqueo automático de funcionalidades en la app tras el pago, por ejemplo. Para la v1 de Tom, es perfecto: el profe paga vía el enlace, Tom recibe la notificación de Stripe y activa la clase a mano. Cinco clientes al mes es gestionable manualmente; el día que sean cincuenta, conectará la automatización (los «webhooks») — un problema de rico, para más adelante. Automatizar lo que solo ocurre cinco veces al mes es un mal negocio.

Añadir un toque de IA a tu app

Última conexión, la más sabrosa: usar la IA dentro de tu app — y ya no solo para construirla. La idea de Tom: cuando un alumno marca su último hábito del día, aparece un breve mensaje de ánimo personalizado, generado por la API de Claude. Misma arquitectura que el email: función servidor, clave en variable de entorno, límite de uso. Con dos precauciones nuevas, propias de la IA:

Añade una función «ánimo del día» a mi app de seguimiento de hábitos.
Cuando el usuario marca su último hábito del día, llama a la API de Claude desde una función servidor de Vercel para generar un breve mensaje de ánimo personalizado:
- tono cálido pero no ñoño, adaptado a alumnos de instituto
- menciona la racha actual y el hábito más regular de la semana
- 2 frases como máximo, en español
Restricciones técnicas:
1. la clave API se queda en una variable de entorno, únicamente en el lado servidor
2. límite: una llamada por usuario y por día
3. prevé un mensaje por defecto simpático si la llamada falla o supera los 5 segundos — la app no debe romperse NUNCA por culpa de esta función
Muéstrame el texto exacto del prompt que la función enviará a Claude, para que pueda ajustarlo.

Dos líneas merecen tu atención. «Prevé un mensaje por defecto si la llamada falla»: es la degradación elegante — una funcionalidad extra no debe poder romper nunca la app que la sostiene. Y «muéstrame el texto exacto del prompt»: pues sí, tu app contiene ahora ella misma un prompt, que puedes refinar como has aprendido a refinar los tuyos. Escribes prompts que generan código que envía prompts — el bucle es sabroso, y dominas cada piso.

Cuando un servicio externo se cae

Última lección de este capítulo: tu app depende ahora de servicios que no controlas. Resend, Stripe o la API de Claude pueden tener una avería, ralentizarse, o cambiar sus reglas. Tres hábitos en proporción: verificar la página de estado del servicio antes de buscar el bug en tu código («Resend status» en un buscador), prever un comportamiento de repliegue para cada conexión (mensaje por defecto, botón desactivado con explicación), y no hacer depender nunca la función núcleo de tu app de un servicio externo. Los hábitos de Tom se marcan incluso si la IA, el email y el pago están los tres caídos — eso es una arquitectura sana.

Tu app ya sabe escribir, cobrar y pensar. Pero cada conexión también ha agrandado su superficie de exposición: claves que proteger, entradas que validar, límites que hacer respetar. Antes de ir más lejos, es hora de asegurar seriamente el conjunto — ese es el programa del capítulo 9.