AI needs APIs

Everywhere you look, someone’s building (or selling) some “AI-powered” something — from chatbots that help you order cat food, to full-blown agent frameworks that will schedule your meetings, optimize your finances, and maybe (accidentally) tweet from your account. 

It’s the shiny new thing that’s captured the hearts, minds, and pocketbooks of those criminally online.  While this post isn’t here to argue the various nuances of the technology or if/when/how it should be used, but rather - demystify the “magic” behind the stack with some unglamorous truths. 

This current hype cycle wouldn’t even be possible without APIs.  While the concept of Application Programming Interface has been around since the early days of computing, the modern Web API as we know it came to be in the 2000s. 

Now, this same technology is powering the next wave of innovation in tech - AI. 

Newsflash: your “magic” AI agent or MCP server is just APIs calling other APIs.

Under the hood of your AI agent, low-code tool, or custom model pipeline is the digital equivalent of a switchboard operator plugging wires together. If you’ve ever wondered why something “suddenly stopped working,” nine times out of ten it’s not the AI’s fault. It’s because some API endpoint moved, rate limits got hit, or authentication went sideways.

In other words: you can’t be good at AI engineering in 2025 without understanding the fundamentals of how the web is glued together.

What’s really happening under the hood

Let’s strip away the buzzwords for a second. Whether you’re:

• Chaining together OpenAI, Slack, and Notion with Zapier
• Building an agent in Mastra or LangChain that queries your database
• Writing a bespoke Python script to scrape data, process it, and push it somewhere else

…you’re dealing with the same thing:

• HTTP requests: GET, POST, PUT, DELETE (and the occasional PATCH if you’re feeling fancy)
• JSON payloads: The lingua franca of modern systems
• Authentication: Usually some flavor of API key, OAuth token, or signed request
• Error handling: Where your debugging skills truly get tested

How to actually learn this layer

If you’ve only ever used APIs through SDKs or drag-and-drop tools, you might think of them as this mysterious “black box” where you send stuff and hope something good comes back. But APIs aren’t magic — they’re just structured ways for computers to talk to each other. And like any good conversation, the details matter.

Here’s how I’d approach learning this layer in 2025: 

1. Learn to make a raw HTTP request: Skip the fancy wrappers at first. Use curl in the terminal or Python’s requests library.
2. ACTUALLY read the API docs, there is treasure in there! 
   1. Focus on: authentication, endpoint structure, query parameters, and error codes.
   2. The gold is usually buried in the “Response” examples.
3. Chain two APIs together manually
   1. Example: Grab weather data from an API, then send it as a Slack message via the Slack API. Do it with Zapier first, then try your hand at doing it without Zapier and compare.
4. Work with webhooks: APIs don’t always wait for you to call them — sometimes they call you.
   1.  Set up a small Flask server to receive a webhook from Stripe, GitHub, or Twilio. You’ll suddenly understand half the “automation” talk you see on LinkedIn.

Let’s break down the anatomy of an API call:

1. Base URL – The address of the house you’re knocking on.
   • Example: https://api.github.com
   • If this is wrong, you’re not even in the right neighborhood.
2. Endpoints – The specific door you’re knocking on.
   • Example: /users/{username}/repos
   • This tells the API what you want. Different endpoints = different data/actions.
3. HTTP Methods – The verb of your request.
   • GET: Give me data.
   • POST: Take my data.
   • PUT/PATCH: Update my data.
   • DELETE: Destroy my data. (Use with caution, or regret.)
4. Headers – The polite introduction.
   • Includes authentication (Authorization: Bearer YOUR_API_KEY), content type (application/json), and sometimes rate limit hints.
   • Forget your headers, and you’ll be ignored like a cold sales email.
5. Body (Payload) – The message you’re sending, usually JSON.
6. Response – The API’s reply, also usually JSON.
   1. Includes your requested data and crucial info like status codes (200 OK is your friend, 404 Not Found is… not).

Different types of APIs you’ll encounter

Not all APIs are REST with JSON. Here’s a quick sampler platter:

• REST APIs – The most common, easy to read, uses HTTP methods + JSON.
• GraphQL – Lets you ask for exactly the data you want (and only that). Great for reducing over-fetching.
• WebSockets – For real-time updates without constant polling.
• gRPC – High-performance, binary-based communication. More common in microservices.
• SOAP – XML-heavy, enterprise-y, still lurking in legacy systems.

Final word: AI Engineering ≠ only AI

AI engineering in 2025 is as much about network literacy as it is about prompt engineering.

The engineers who thrive aren’t just the ones who know which LLM model to pick — they’re the ones who can debug a failing webhook, gracefully handle a 429 rate limit, and stitch together three different services without rage-quitting.

Learn the plumbing. Own the pipes. Then, make magic happen ✨