Coder Legion - Recent posts tagged apis

What Are APIs? And How Do They Work?

Thu, 15 Oct 2026 13:41:10 +0000

A beginner-friendly guide, with a bit of Python and a lot of food analogies.

Imagine you're building a weather application, and it needs to show the current temperature in Mutare. There's just one problem: you don't own any weather sensors, and you definitely don't have a meteorological database lying around. Building that infrastructure yourself would be a huge project. Why reinvent the wheel? So you borrow the data from a service that already has it.

The tool that makes this possible is something developers use all the time, often without noticing: an API.

Welcome to another article, where we talk about APIs. Why they're needed, what they are, how they work, types of APIs, and show an example of a code block using an API.

In simple terms, an API is a defined interface that lets one piece of software interact with another. If you like, think of APIs as the cellphones of applications: they give programs a set way to call each other up and ask for things, like: "Hey, can I have all the PDF documents on machine learning for beginners?"

In this article, we'll cover what APIs are, how they work, how to make your first API request in Python, the main types you'll hear about, and five beginner projects to practise on.

Why Do Applications Need to Communicate?

Modern applications rarely work alone. They depend on data and services provided by other systems.

Take a food delivery app. It needs restaurant menus, a payment service, a map to show your location, and live tracking so you can follow your food as it's being delivered. Each job belongs to a different system, and the app connects to them instead of building everything itself.

The same is true for AI applications. A chatbot might send a prompt to an AI model through one API, then fetch relevant information from a database through another, and combine both to write its answer. Each part has one responsibility, and each is reached through its own interface.

Now let's bring this closer to home. In my current capstone project, we have five group members, each with different roles and strengths. We can't just disappear into our corners and hope everything magically fits together at the end. We need agreed rules: who builds what, what each piece takes in, and what it hands back.

Software components need the same thing. Without a clearly defined way to talk to each other, they can't reliably work together. That defined way of making requests and passing information is the API.

What Is an API?

Six months ago, I didn't even know what the letters stood for. Today I can tell you that API stands for Application Programming Interface.

Here's the more precise definition. An API is a defined interface that allows one software component to interact with another. It specifies how requests can be made, what information or functionality is available, and how the receiving system communicates the result (Amazon Web Services, n.d.).

The application using the API doesn't need to know all the internal details of the system providing the service. It needs to understand the interface and follow the rules for using it.

Think of a restaurant menu. It tells you what you can order and what to expect back: "Quarter chicken and chips with lettuce", and sometimes even a picture of the plate you're about to get.

You don't need to know how the kitchen works, where the ingredients are stored, or what the chef does behind the scenes. You look at the menu and place your order. That's it.

In this analogy, the menu is the API (the interface), and your order is the request. It's basically: "I want this. I don't need to know how you do it, but here's how I'll ask for it."

A quick caveat, though. The menu doesn't cook anything. In a typical web API, the API defines the interaction, while the server behind it does the actual work. Keep that in mind, because we'll come back to it.

APIs aren't only for the internet

Note: An API isn't necessarily a website, a database, or something that runs over the internet. APIs also exist inside programs. For example, a software library has an API that tells you which functions you can call, and an operating system has APIs that let programs open files or draw things on screen.

How Do APIs Work? The Request-Response Cycle

Let's put the restaurant to work. You're hungry and you order a burger:

You place an order (request). Your application asks for something, like the current weather in Mutare.
The kitchen gets to work (processing). The server receives the request and prepares what was asked for.
Your food arrives (response). The server sends the result back, and your application displays it.

Here's how the roles line up:

The menu is the interface and its rules.
The customer is the client (your application).
The kitchen is the server that processes the request.
The meal is the response.

In a typical web API interaction, the client sends a request to an endpoint (a specific web address) using a defined format and method. The server receives the request, validates it, and performs the required operation, which may involve retrieving data or communicating with another service. It then returns a response, often containing a status code and data formatted as JSON (MDN Web Docs, n.d.).

What happens when something goes wrong?

Not every order ends with a delicious burger. You might order something that isn't on the menu (an invalid request), the kitchen might run out of ingredients (a server error), or the waiter might never make it to your table (a network problem). If something goes wrong, the server may return an error response instead, and the client should be ready to handle both successes and failures.

Making Your First API Request in Python

Enough theory. Let's actually use an API!

We'll use Python and JSONPlaceholder, a free fake online REST API built for testing and experimentation. It lets us practise a simple request without building our own backend.

First, install the requests library:

pip install requests

Next, the code:

import requests

url = "https://jsonplaceholder.typicode.com/posts/1"

try:
    response = requests.get(url, timeout=10)
    response.raise_for_status()
    post = response.json()
    print(f"User ID: {post['userId']}")
    print(f"ID: {post['id']}")
    print(f"Post Title: {post['title']}")
    print(f"Post Body: {post['body']}")
except ValueError:
    print("The response was not valid JSON.")
except requests.RequestException as error:
    print("Request failed:", error)

That's it, we've just made an API request! Here's what's happening, in plain language:

requests.get(url, timeout=10) sends an HTTP GET request, which means "please give me this." It's us placing our order. The timeout=10 tells Python to stop waiting after 10 seconds, so our program doesn't hang forever if the kitchen has vanished.
response.raise_for_status() checks whether the request succeeded. If the server answers with an error status code (like 404 for "not found" or 500 for "server problem"), it raises an exception instead of letting the program carry on as if nothing happened (Requests, n.d.).
response.json() parses the response body, which means it turns the JSON text into Python data (here, a dictionary) that we can work with. If the body isn't valid JSON, this step fails.
post['userId'], post['id'], post['title'] and post['body'] each read one field from that dictionary: who wrote the post, the post's own number, its title and its text. The f-strings add a label in front of each value so the output is easy to read.
The except blocks are our safety net. One catches invalid JSON, and the other catches request failures such as timeouts, connection problems and bad status codes. Either way, we print a readable message instead of crashing.

Here's what I got when I ran the code:

The API returns a sample post with a user ID, a post ID, a title and a body, and those are the four values we printed. We don't know how the service stores that data, and we don't need to. We use the interface and work with what comes back.

Tip: Run this code yourself and then break it on purpose. Change the URL to /posts/99999 or remove a letter from the address, and watch which error message appears. You'll learn more from the failures than from the success.

Types of APIs: REST, SOAP, GraphQL and WebSockets

Do all APIs work the same way? The short answer is no. Here are four you'll hear about often.

REST APIs

REST is an architectural style commonly used to build web APIs, often over HTTP. Resources like users, products or blog posts are accessed through addresses. Our JSONPlaceholder example was a REST API.

Use it when: you're building a standard web or mobile backend. It's a sensible starting point for most beginners.

SOAP APIs

SOAP is a messaging protocol that exchanges structured messages, usually written in XML, under strict rules. It's more rigid than REST and is often found in older or enterprise systems.

Use it when: you're integrating with a system that already requires it, such as some banking or enterprise services.

GraphQL APIs

GraphQL is a query language and runtime. Clients can request the specific fields they need, within the limits of the server's schema and permissions. An app showing a profile page might ask only for a user's name and email instead of their entire record.

Use it when: different screens or clients need different slices of the same data.

Further reading: The official GraphQL introduction explains queries and schemas.

WebSocket APIs

WebSockets provide a persistent, two-way connection, instead of the usual "ask once, answer once" pattern of HTTP. They can support real-time APIs.

Use it when: you need constant live updates, such as chat, multiplayer games or live dashboards.

These aren't all the same kind of thing

Here's the part that confused me at first: these four aren't competing options from the same category. REST is an architectural style, SOAP is a protocol, GraphQL is a query language and runtime, and WebSocket is a communication protocol. They also aren't mutually exclusive. A single application might use REST for normal data, GraphQL for flexible queries and WebSockets for live notifications.

There's no single API style that fits every situation. The right choice depends on what you're building.

Why APIs Matter (and Where They Can Hurt)

APIs let developers build on existing technology, combining services into applications that would be far more complicated to create alone.

If you're into AI like I am, this matters even more. Picture an AI-powered application that uses a language model, retrieves information from a database and processes payments, all through separate APIs.

An AI model and an AI API are not the same thing. The model performs the inference, while an API can provide a defined way for an application to send input to a hosted model and receive its output. This means developers can build AI-powered applications without necessarily hosting the model themselves, although they still need to manage the surrounding application logic, security and usage costs.

The trade-offs of depending on someone else's API

Although APIs make integration easier, they also introduce considerations such as authentication, rate limits, security and reliability. Some services require API keys, while others restrict the number of requests a client can make or charge based on usage. Requests can also fail because of network issues or server errors. Developers should protect private credentials, follow the provider's usage requirements, and design applications to handle failures gracefully.

There's also dependency risk. An external API can change, go offline, impose quotas or start charging for something that used to be free. Your app is only as reliable as the services it leans on.

Further reading: The OWASP API Security Project lists the most common API security risks and how to reduce them.

5 Beginner API Projects to Practise With

Now let's practise. Each project below has a clear finish line and at least one error case to handle. The difficulty ratings are rough guides, not universal truths, so a project may feel easier or harder for you. Always check each provider's current documentation for key, account and usage requirements, since these can change.

1. Weather app (beginner)

Build an app that shows the temperature, humidity and current conditions for a place of your choice. Use Open-Meteo, which offers weather data as JSON and, at the time of writing, doesn't need an API key for its free, non-commercial use.

You'll practise: GET requests, query parameters, JSON responses and displaying data.
Success looks like: typing a city's coordinates and seeing its current weather on screen.
Error case to handle: the request times out or the service is unreachable.

2. Random cat image generator (beginner)

A tiny app that shows a new cat picture each time someone clicks a button. Simple, fun and surprisingly good for the basics. Use The Cat API, and check its docs for current authentication and usage requirements.

You'll practise: making requests, handling responses, displaying images and responding to clicks.
Success looks like: a new cat appears on every click.
Error case to handle: the image fails to load, so show a friendly message instead of a broken picture.

3. Book finder (beginner)

Let users search by title or author and show titles, authors, publication dates and cover images with the Google Books API.

You'll practise: search queries, query parameters, looping through multiple results and displaying structured data.
Success looks like: searching "Things Fall Apart" and seeing a list of matching books.
Error case to handle: a search that returns no results. Show "No books found" rather than a blank page.

4. Movie search app (beginner to intermediate)

Build a movie lookup that shows titles, release dates, ratings and posters using The Movie Database (TMDB) API. Check the current requirements for accounts, API keys, attribution and usage before you start.

You'll practise: authentication, search queries and displaying data in a user interface.
Success looks like: searching for a film and seeing its poster, rating and release date.
Error case to handle: an invalid or missing API key.

5. AI chatbot (intermediate)

Build a simple chatbot that sends a user's message to an AI model and displays the reply. Follow the OpenAI API quickstart to make your first request. Hosted model APIs need a key and may charge for usage, so keep an eye on costs.

You'll practise: POST requests, sending data in a request body, authentication and handling AI-generated responses.
Success looks like: typing a question and getting a model-generated answer back.
Error case to handle: the request fails, the rate limit is hit or the key is invalid.

Warning: Never put private API keys in frontend code or commit them to GitHub. For a web app, make the API call from your server and load the key from an environment variable.

Where Should You Start?

If you've never worked with APIs before, start with the cat generator or the weather app. Both let you focus on the fundamentals without much application logic getting in the way.

Once you're comfortable, move on to the book finder and movie search. Save the chatbot for when you're ready to deal with authentication, POST requests and keeping secrets safe.

Start small, experiment, break things, and build your way up. The goal isn't only to finish the projects. It's to understand what happens each time your application talks to another service.

Frequently Asked Questions

Do I need to know how a server works to use an API?

No. That's the whole point of an interface. You need to understand how to ask and what you'll get back, not how the system works internally.

What's the difference between an API and an API key?

The API is the interface. The API key is like a membership card that some providers require so they know who is making requests and can apply limits or charges.

Is a free API really free?

Often, but usually with limits. Check the provider's documentation for rate limits, usage rules and whether free access is allowed for your kind of project.

Conclusion

An API is a defined interface that lets software components interact without needing to know each other's inner workings, much like ordering from a menu without visiting the kitchen.

In a typical web API, the client sends a request, the server processes it, and a response comes back, which might be data or an error.

We saw this in Python with requests, adding a timeout, raise_for_status() and exception handling so the code copes with failure.

REST, SOAP, GraphQL and WebSockets are different tools that can even live in the same app.

APIs make integration possible, but they bring authentication, rate limits, costs and dependency risks. Start with a small project, break it on purpose, and learn from what happens.

Now that you know what's going on behind the scenes, the next time you use an app, you might catch yourself wondering which APIs are making it work.

Happy coding!

See you next time!

References

Amazon Web Services. (n.d.). What is an API? Amazon.com. Retrieved October 14, 2026, from https://aws.amazon.com/what-is/api/

MDN Web Docs. (n.d.). HTTP. Mozilla. Retrieved October 14, 2026, from https://developer.mozilla.org/en-US/docs/Web/HTTP

Requests. (n.d.). Quickstart. Requests documentation. Retrieved October 14, 2026, from https://requests.readthedocs.io/en/latest/user/quickstart/

Jev Model API

Fri, 02 Oct 2026 20:39:51 +0000

Jev Model is a System One decision model for developers. It accepts shared state as text, JSON objects, or arrays of text and answers up to eight Choice, Score, or Noul questions in parallel. It returns structured outputs with probabilities for classification, routing, scoring, guardrails, and human-review workflows.

Try the free unlimited online playground: https://jevmodel.net/

The website also provides documentation, API access, and paid access plans for teams. The project’s GitHub organization is https://github.com/jev-ai

From Tutorials to Real Projects: What Building My AI Learning Companion Is Teaching Me.

Mon, 07 Sep 2026 12:29:42 +0000

One thing I’m beginning to appreciate about learning software development is that understanding a concept and using it to build something are two different experiences.

You can understand what a function does, how a class works, or how an API is supposed to work. But when you start putting everything together into a real project, you begin to see how those concepts connect.

That’s what I’ve been experiencing while building my AI-Powered Learning Companion using Python.

The idea behind the project is to create a tool that helps learners practice by generating study questions, evaluating answers, and tracking their progress.

At first, the idea sounded straightforward.

Then I started building.

I had to think about how to organize the application, how to structure the data, how different parts of the program would communicate, and how to handle situations when something didn't work as expected.

And that’s where the learning became much more practical.

The bugs became part of the lesson

One thing I’ve learned is that debugging is not just about fixing an error and moving on.

Sometimes, an error makes you realize that you didn't fully understand how something worked in the first place.

Other times, you discover that the problem isn't where you thought it was.

So I’ve been learning to slow down, read the error messages, understand what the code is actually doing, and try to solve the problem instead of just rushing to make it disappear.

I’m still working on this, but I’m definitely becoming more comfortable with the process.

🤖 Learning to work with APIs

Another interesting part has been learning how to connect the application to an AI language model.

This has introduced me to things like:

Working with API requests
Handling responses
Managing errors
Understanding API credentials
Thinking about how an external service fits into my application

It has also reminded me that building an AI application involves more than just calling an AI model.

You still need to think about the application itself, how users interact with it, and how the information is stored and used.

Seeing the bigger picture

One of the things I’m enjoying most is seeing how different concepts come together.

Python is no longer just something I use to practice individual exercises.

I’m beginning to see how it can be used to build something that has a purpose.

And that has been really encouraging.

I’m also continuing to learn JavaScript, so I’m excited to see how that will expand what I can build in the future.

I’m still learning, and this project is still a work in progress.

But I’m starting to understand why people say that building projects is one of the best ways to learn programming.

You don't just learn how something works.

You learn how to make it work.

And sometimes, you learn the most when it doesn't.

What was the first project that made programming feel practical for you?

Where No-Code Stops Being Code

Fri, 28 Aug 2026 17:19:28 +0000

Most of us here have been handed a no-code prototype and asked to make it production ready. This is a look at where that handoff usually breaks, and what changes when the platform emits real server side code instead of a configuration blob.

The Ceiling Is The Component Library

A visual builder can only express what its component library supports. Simple CRUD, an internal admin tool, a prototype for a stakeholder, all fine. The wall arrives the first time you need a pricing function that reads inventory levels and seasonal patterns, or an endpoint that accepts a webhook from an obscure vendor and reshapes the payload for your CRM.

At that point there are two exits, and both are expensive. You invent a workaround nobody can maintain, or you throw the build away and start again in code with the requirements you should have written down in the first place.

Generated Code Moves The Ceiling To Your API Surface

When the output is actual server side code rather than a saved configuration, the constraint changes shape. You are no longer bounded by a predefined set of blocks, you are bounded by whatever your APIs and your data will allow. Custom logic, scheduled jobs, storage and your own endpoints are all just code the generator can write.

The tradeoff is worth stating honestly. Visual builders let you watch the thing take form as you assemble it, which is a real advantage if you think by dragging. Generated apps ask you to describe the requirement clearly before anything exists, which is harder, and which is also why the output tends to be more capable. That is the model behind the platform we build on, where custom apps, chained commands and the ML and chatbot layers all sit on the same generated foundation.

The Chain Is Where The Value Actually Lands

A single generated app is rarely the interesting part. The interesting part is the chain. A form submission fires an enrichment call, the result feeds a scoring step, a condition routes the record, a follow up gets scheduled, and a notification goes out to whoever owns the next decision.

Every one of those steps is trivial on its own. The complexity lives entirely in the wiring, in the branches, and in what the chain does when one call comes back empty. Compose from simple steps and the hard part becomes composition, which is a much better problem to have than a monolith you cannot inspect.

What To Check Before You Trust It

Two things separate a platform you can run a business on from a good demo.

The first is conditional handling on every step that can legitimately return nothing. The silent stall is the failure mode nobody plans for, and it is the one that gets discovered on Thursday when someone asks why the leads stopped arriving.

The second is a readable run history. When a chain fails, you need to open that run and see which call returned what, in order, with the data that was in context at the time. Without that, you have not automated a process, you have only moved it somewhere you cannot watch it.

If a platform gives you real code, real branches and a run log you can read back, the no-code label stops mattering. What you actually have is a code generator with hosting attached, and that is a fair thing to put in front of a business.

How Backboard.io Transformed My Multi-Agent AI System

Tue, 14 Apr 2026 12:56:36 +0000

I built Londoolink AI to help users stay on top of their day by generating personalized briefings from emails, calendar events, Notion pages, and social media.

It worked well and pulled together useful insights, but it had one major flaw.

It forgot everything.

Every time a user came back, it was like starting over. Preferences were lost, conversations had no context, and the experience felt repetitive. The system was smart, but it didn’t feel intelligent.

That changed when I integrated Backboard.io.

You can view the project here: https://londoolink-ai.vercel.app/

1. The Problem: No Memory

Before the integration, users had to:

Repeat their preferences every day
Re-explain what mattered to them
Ask the same follow-up questions again

Even though the system could analyze data well, it didn’t learn from users over time.

2. The Shift to a Stateful System

I first came across Backboard.io through an email after submitting my project to an Auth0 Hackathon on Devpost. The team had reached out, sharing more about the platform and how it enables AI systems to become stateful through persistent memory, threads, and tool-calling.

That sparked my curiosity, so I explored it further during MLH Global Hack Week: API, where I got to understand more about how it actually works in practice.

What stood out was simple but powerful:

Instead of building memory from scratch, Backboard provides it out of the box.

3. What Changed

Persistent Memory

Now, users can store preferences like:

Preferring meetings in the morning
Prioritizing certain emails

And the system remembers them.

Here’s a simplified version of how I store preferences:

This function saves a new piece of memory (like a user preference) for a specific assistant using Backboard’s API.

class BackboardService:
    def add_memory(self, assistant_id, content):
        response = requests.post(
            f"{self.base_url}/assistants/{assistant_id}/memories",
            headers=self.headers,
            json={"content": content}
        )
        return response.json()

Retrieving preferences:

This function searches stored memories and returns anything related to user preferences so the assistant can personalize responses.

def get_preferences(self, assistant_id):
    response = requests.post(
        f"{self.base_url}/assistants/{assistant_id}/memories/search",
        headers=self.headers,
        json={"query": "user preferences"}
    )
    return response.json().get("memories", [])

Better Document Retrieval

I moved from a local setup to a cloud-based system.

This function uploads documents (like notes or data sources) to the cloud so they can be retrieved and used by the AI system later.

def add_document(self, content, metadata):
    return requests.post(
        f"{self.base_url}/documents",
        headers=self.headers,
        json={
            "content": content,
            "metadata": metadata
        }
    )

This improved both scalability and search quality.

Threaded Conversations

Now users can ask follow-up questions with full context.

This function creates a conversation thread tied to a specific user so all messages stay connected.

def create_thread(self, user_id):
    response = requests.post(
        f"{self.base_url}/threads",
        headers=self.headers,
        json={"metadata": {"user_id": user_id}}
    )
    return response.json()["thread_id"]

Adding messages to a thread:

This appends a new message (from a user or an assistant) to an existing conversation thread to maintain context.

def add_message(self, thread_id, role, content):
    requests.post(
        f"{self.base_url}/threads/{thread_id}/messages",
        headers=self.headers,
        json={"role": role, "content": content}
    )

4. How It All Comes Together

In my main agent:

This is the full flow:

Get or create an assistant
Fetch stored user preferences
Generate a personalized briefing
Create a conversation thread for follow-ups

def create_briefing(self, user_id):
    assistant_id = self.get_or_create_assistant(user_id)

    preferences = self.get_preferences(assistant_id)

    briefing = self.generate_briefing(
        data_sources,
        user_preferences=preferences
    )

    thread_id = self.create_thread(user_id)

    return {
        "briefing": briefing,
        "thread_id": thread_id
    }

5. Challenges Along the Way

One issue I ran into was handling API responses.

The API sometimes returned 201 instead of 200, so I updated my handler:

if response.status_code in (200, 201):
    return response.json()

I also had to handle endpoint inconsistencies like /memory vs /memories, and made response parsing more flexible.

6. The Impact

Before Backboard	After Backboard
No memory	Remembers user preferences
Generic outputs	Personalized results
No conversation continuity	Context-aware conversations

7. Key Takeaways

Memory makes AI feel like an assistant, not just a tool
A simple service layer keeps integrations clean
Small API details matter more than you think

8. Shoutout

I learned more about Backboard.io during the ongoing MLH Global Hack Week: API Week 2026, a week-long online hackathon by Major League Hacking (MLH) focused on APIs, building, and learning through live sessions and community challenges.

Big shoutout to the MLH community and organizers for creating an environment where developers can explore tools like this while building real-world projects and learning by doing.

9. Final Thoughts

This integration changed my system from something that generates results into something that understands users over time.

If you’re building AI applications, adding memory is one of the most impactful upgrades you can make.