Connecting services: emails, payment, AI

The app that talks to the world

The success of Tom's app reaches beyond his class: a colleague who teaches French uses it with her eighth-graders, and a math teacher from another school wrote to ask "how to set it up for his school — and how much it costs". Three wishes emerge: send students a weekly recap by email, add an AI-generated encouragement message when a student finishes their day, and offer a paid "classroom" version for teachers at other schools. Three features, one shared mechanism: making his app talk to external services.

That dialogue happens through APIs (programming interfaces). The principle: a service — Resend for emails, Stripe for payment, Claude for AI — exposes a counter on the Internet. Your app shows up with a structured request ("send this email to this address") and an API key that proves its identity, and the service executes then replies. You don't need to understand how Resend routes an email, any more than you need to understand a power plant to plug into an outlet: the API is the outlet.

The golden rule: keys stay server-side

Before any wiring, an absolute rule. Your API key is a bank card: whoever holds it consumes the service in your name and at your expense. And all the code running in a browser is readable by anyone — a simple F12 is enough. The inescapable conclusion: a secret key must never sit in browser-side code. It lives server-side, where nobody can read it.

"But I don't have a server!" Yes you do, almost: Vercel (and its competitors) offers server functions — small pieces of code hosted on their side, executed on demand. The pattern is always the same: the browser calls your server function (no key), the function calls the external service (with the key, stored in an environment variable), and returns only the result to the browser. The AI knows how to create these functions perfectly — your job is to demand this architecture in your prompts.

flowchart LR
  N["Student's browser"] -->|"Request without any key"| F["Server function on Vercel"]
  F -->|"Call with the secret key"| S["External service: Resend, Stripe or Claude"]
  S -->|"Response"| F
  F -->|"Clean result"| N

Sending emails: the weekly recap

First connection: email. You don't send automated emails from your Gmail inbox — providers block it fast and it's fragile. You go through a transactional email service like Resend, Postmark or Brevo: built for apps, reliable, and free at small scale (Resend offers 100 emails per day, far beyond Tom's needs). Tom's prompt, in full:

Add a recap email feature to my habit-tracking app.
Context: HTML/JS app on Vercel, data in Supabase, magic link authentication.
What I want:
1. a "send me my weekly recap" button on the main page
2. on click, a Vercel server function computes the logged-in user's streaks and checks for the week, and sends them a clean, readable email via Resend
3. the Resend API key stays server-side, in a Vercel environment variable — never in browser code
4. strict limit: one send per user per day maximum, with a clear message if the limit is reached
First guide me through creating the Resend account and configuring the environment variable on Vercel, then code the function.
One step at a time, I'll wait to test before the next one.

Pause on line 4: "one send per user per day". Why limit a free feature? Because any button that triggers an external service can be hammered — by a prankster student or by a bot — and every send consumes your quota. Setting a limit at design time is an architect's reflex: you protect your service before it needs it. We'll generalize this reflex in chapter 9.

Taking a payment without coding: Stripe Payment Links

For the paid "classroom" version, Tom fears the worst: online payment is serious, regulated, anxiety-inducing. Good surprise: Stripe, the payment service most used by developers, offers Payment Links — payment pages hosted by Stripe, created in a few clicks in their dashboard, without a single line of code. You create a product ("Classroom plan — $29/year"), Stripe generates a URL, and your app only has to show a button pointing to that URL. Stripe handles the bank card, security, invoicing, refunds.

• Create an account on stripe.com and stay in test mode for now.
• In the dashboard: Products → add "Classroom plan" with its price.
• Generate the product's Payment Link and copy the URL.
• Ask the AI to add a "classroom plan" page with the benefits and a button to that link.
• Test the full journey in test mode, then switch to live mode once everything is validated.

Payment Links have limits — no automatic feature unlocking in the app after payment, for instance. For Tom's v1, that's perfect: the teacher pays via the link, Tom receives the Stripe notification and activates the classroom by hand. Five customers a month is manageable manually; the day there are fifty, he'll wire up the automation (the "webhooks") — a nice problem to have, for later. Automating something that happens only five times a month is a bad deal.

Adding a touch of AI to your app

Last connection, the most delightful: using AI inside your app — and no longer just to build it. Tom's idea: when a student checks off their last habit of the day, a short personalized encouragement message appears, generated by the Claude API. Same architecture as the email: server function, key in an environment variable, usage limit. With two new precautions, specific to AI:

Add a "daily encouragement" feature to my habit-tracking app.
When the user checks off their last habit of the day, call the Claude API from a Vercel server function to generate a short personalized encouragement message:
- warm but not cheesy tone, suited to middle-schoolers
- mention the current streak and the most consistent habit of the week
- 2 sentences maximum, in English
Technical constraints:
1. the API key stays in an environment variable, server-side only
2. limit: one call per user per day
3. plan a nice default message if the call fails or takes more than 5 seconds — the app must NEVER break because of this feature
Show me the exact text of the prompt the function will send to Claude, so I can adjust it.

Two lines deserve your attention. "Plan a default message if the call fails": that's graceful degradation — a bonus feature must never be able to break the app that carries it. And "show me the exact text of the prompt": that's right, your app now contains a prompt of its own, which you can refine just like you learned to refine yours. You write prompts that generate code that sends prompts — the loop is delicious, and you're in control of every level.

When an external service goes down

Last lesson of this chapter: your app now depends on services you don't control. Resend, Stripe or the Claude API can have an outage, slow down, or change their rules. Three proportionate habits: check the service's status page before hunting for the bug on your side ("Resend status" in a search engine), plan a fallback behavior for every connection (default message, disabled button with an explanation), and never make your app's core feature depend on an external service. Tom's habits can be checked off even if the AI, the email and the payment are all three down — that's what a healthy architecture looks like.

Your app now knows how to write, charge and think. But each connection has also enlarged its exposure surface: keys to protect, inputs to validate, limits to enforce. Before going further, it's time to seriously secure the whole thing — that's the agenda of chapter 9.