APIs, Keys & GitHub
Three things every tutorial assumes you know. If any of them are fuzzy, this is the most important chapter in the guide.
APIs: How Software Talks
When your app needs to do something it can't do itself — process a payment, send an email, generate an image — it makes an API call to another service. Your app sends a request, the service does the work, and sends a response back.
A structured way for one piece of software to send a request to another and get a response back. Think of it as a menu at a restaurant — it lists everything the kitchen can make and how to order it.
The API is your waiter. You tell the waiter what you want (request), the kitchen makes it (processing), the waiter brings it back (response). You never go into the kitchen yourself. The menu is the API documentation — it tells you what you can order and how to ask for it.
API Keys: Your Permission Slip
Every service gives you a key — a unique string that identifies you. When your app makes an API call, it includes the key so the service knows who's asking and whether they're allowed.
The golden rule: never put API keys in your code. Store them in environment variables instead. If a key ends up in your code and that code goes to GitHub, anyone can find it and use your account.
A unique string that identifies you to a service. Like a password for software. Leak it and anyone can use your account — and run up your bill.
A value stored outside your code that your app reads at runtime. This is where keys live safely — in a file on your computer that never gets uploaded to GitHub.
# Your secret keys live here
STRIPE_SECRET_KEY=sk_live_abc123...
AI_API_KEY=sk-ant-abc123...
DATABASE_URL=postgresql://...
# This file is NEVER uploadedGitHub: Where Your Code Lives
GitHub is your recipe binder with timestamps. Every time you change a recipe, the old version is saved. If the new version is terrible, flip back to last Tuesday's. No recipe is ever truly lost.
Git tracks changes. GitHub hosts your code in the cloud. You need to understand four commands — that covers 95% of daily use as a solo founder.
A project folder on GitHub. Contains all your code, its history, and configuration files. Like a binder that holds every version of every recipe you've ever written.
A snapshot of your code at a specific moment. Like taking a photo of your recipe binder so you can always go back to that exact version.
# Stage your changes
git add .
# Save a snapshot with a note
git commit -m "added pricing page"
# Upload to GitHub
git push
# Download latest from GitHub
git pullThat's it. Four commands. add stages changes, commit saves a snapshot, push uploads, pull downloads. Everything else is edge cases you'll learn as you go.
How These Three Connect
The security chain. Break any link and you're exposed.
Set up your .gitignore before your first commit. Not after. The moment a key hits GitHub's history, it's compromised — even if you delete it later. GitHub scans for exposed keys and services revoke them automatically, but the damage window can be expensive.
APIs are the waiter who takes your order. API keys are your membership card that proves you're allowed to order. GitHub is the recipe binder that stores every version of your restaurant's recipes. The .gitignore is the "do not photocopy" stamp on your confidential recipes.