Three things every tutorial assumes you know. If you already know them, skip ahead. If you don't, this is the most important chapter in the guide.
This entire chapter covers three things: APIs, keys, and GitHub. If you already know what these are, skip to Chapter 4. If these words mean nothing to you, this might be the most important chapter in the guide.
DEF: API (Application Programming Interface) — How software talks to other software. When your app needs to send a text message, it doesn't build a cell tower. It asks Twilio's API to send it. An API is a waiter who takes your order to the kitchen and brings back the food.
DEF: API Key — Your permission slip. Every API requires one. It tells the service who's making the request and whether they're allowed to. Lose it, and someone else racks up your bill. Leak it publicly, and you'll find out in your credit card statement.
DEF: GitHub — Where your code lives. Think of it as Google Drive for code, but with a complete history of every change ever made. If you accidentally delete something, you can go back in time and get it.
Here's what happens when your app checks whether a user has paid for a subscription:
Step 1: Your app sends a request to Stripe's API. The request says: "Hey Stripe, does this customer have an active subscription?"
Step 2: Stripe checks its records and sends back a response: "Yes, they're on the Local plan, paid through April 15."
Step 3: Your app reads the response and decides what to show the user.
That's it. Request, response. Every API interaction in every product in the world follows this pattern.
RESTAURANT: An API is the window between the dining room and the kitchen. You write your order on a ticket, slide it through the window, and the kitchen slides back a plate. You never go into the kitchen. The kitchen never comes into the dining room. The window is the API.
Your API keys are passwords. Treat them like passwords.
Never put keys in your code. Use environment variables — a separate file that your code can read but that never gets uploaded to GitHub. The file is called .env and it looks like this:
SUPABASE_URL=https://yourproject.supabase.co
SUPABASE_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
STRIPE_SECRET_KEY=sk_live_abc123...Add .env to your .gitignore file. This tells GitHub to pretend the file doesn't exist. It won't be uploaded, it won't be visible, and it won't appear in your code history.
NOTE: If you accidentally push a key to GitHub, rotating it immediately is the only safe response. GitHub is public by default. Bots scan new commits for API keys within seconds. This is not hypothetical — it will happen to you if you're not careful.
Git tracks every change you make to your code. GitHub hosts that history online. Together, they give you two superpowers:
1. Undo anything. Broke something at 11 PM? Roll back to the version from 9 PM. Every commit is a snapshot you can return to.
2. Work on features without breaking production. Branches let you experiment in a copy of your code. When the experiment works, you merge it back. When it doesn't, you delete the branch and nothing was harmed.
Set up GitHub on day one. Commit after every working change. Write commit messages that describe what changed. Your future self will thank you.