APIs, explained
How your app borrows superpowers from other services.
Build anything real and you'll hit this question fast: how does my app get weather data? Charge money? Answer questions? The answer, always, is an API: the standard way one piece of software asks another for data or favors. Think of APIs as integrations. Instead of building everything, your app borrows capabilities from services that already do each job well.
Example: your app wants to charge $5 to unlock a feature. You are not going to build a payment network, handle credit cards, or deal with fraud. Stripe already does all of that, and their API is the asking mechanism. Your app sends the request (“charge this person $5”), Stripe's machines handle the scary parts, and a confirmation comes back. (API stands for application programming interface; the name is the least interesting thing about it.)
That same pattern covers a huge range of things you might bolt onto an app:
And apps compose them. Say you're building a group-hike organizer for your friends, call it Trailhead. Weekend forecast, a map to the trail, a group text when someone RSVPs. That's three borrowed superpowers and zero meteorology degrees:
Your app's actual job shrinks to asking good questions and displaying the answers nicely. Most software you use daily works exactly this way: a thin, well-designed layer over other people's APIs.
In practice, each service wants you to create an account before it answers your app's questions (they need to know who's asking, which is the next chapter). But the wiring itself? Delegate it. “Use a free weather API to show the weekend forecast” is a complete instruction, and the agent knows what's out there and how to connect it.
