Calling an API

What we're doing today

By the end of this session, you will have written a tiny program that goes out to the internet, asks another computer for live information, and prints the answer back to you. We will use the live price of one US dollar in Ghana cedis as our example. That is the whole goal — by the end you will have pulled a real, fresh number from a real service running somewhere far away, into your own notebook.

This is the lesson where your programs stop being little island things that only know what you typed into them. From today, your code can ask the world questions.

What an API actually is

Imagine you walk up to the counter of a chop bar. You don't go into the kitchen. You don't tell the cook how to fry the plantain. You look at the menu on the wall, you tell the person at the counter what you want, you pay, and a few minutes later they hand you a plate. You don't care how the kitchen works. You only care that the menu tells you what you can order and the plate comes back the way the menu said it would.

An API is exactly that counter. The full name is Application Programming Interface, but the name is not important. What is important is the idea: an API is a service somebody else built that you can talk to over the internet — they define what you can ask and how the answer comes back. Their kitchen, their rules. You just place orders.

The menu of an API is the list of things you can ask for. Each item on the menu is called an endpoint — a specific address you ask for a specific thing. One endpoint might be "give me today's exchange rates." Another might be "give me the weather in Accra." Different counters, different plates.

How the asking happens — HTTP and GET

When you type a website address into your browser and press Enter, your browser is quietly walking up to a counter and placing an order. The language it uses to do that is called HTTP — the way computers ask each other for things on the web. Every time you load a page, watch a video, or check the weather on your phone, HTTP is happening in the background.

There are different kinds of HTTP requests, but the only one you need today is GET — the kind of request where you're asking for information without changing anything. You are not adding anything, you are not deleting anything, you are not logging anyone in. You are just saying "please give me what's at this address." That is a GET.

So when you call an API in Python, what you are really doing is sending an HTTP GET to one of its endpoints and reading what comes back.

The tool we use in Python — requests

Python on its own can speak HTTP, but the built-in way is clumsy. There is a small library called requests that makes it pleasant. In Google Colab it is already installed for you. If you are running Python on your own laptop, you install it once with:

pip install requests

To use it in your code, you bring it in at the top of your file with import:

import requests

import requests is a line that says "Python, fetch the requests toolbox and put it on my desk." From that point on in your program, you can use anything inside that toolbox by writing requests.something.

Your first call

Here is the smallest useful program of the day:

import requests
 
response = requests.get("https://api.exchangerate.host/latest?base=USD")
print(response.status_code)

Run that. You should see the number 200 appear underneath.

Let me unpack each piece.

• requests.get(...) is the function that sends the GET request. You give it the address you want to ask, and it goes off, makes the trip across the internet, and comes back.
• The thing it comes back with, we are storing in a jar called response. That word is just a label — you could call it r or result or reply, but response is what most people use.
• response.status_code is a small number the server sends back to tell you how the request went.

Status codes — the server telling you how it went

Every time you call an API, the server tags its reply with a three-digit number called a status code. This is the server's way of saying "here is how your order went."

You only need to remember one number today:

• 200 means everything worked. The plate came back hot and correct.

Anything in the 400s or 500s means trouble — they're telling you something is wrong. 404 means "I couldn't find what you asked for." 500 means "something is broken on our side." You will see these one day, and when you do, the first thing to check is whether you typed the address correctly. For now, just know: 200 good, anything starting with 4 or 5 bad.

Getting the actual answer out — JSON

So the request worked. But where is the data? It is sitting inside the response object, but not in a form you can use yet. It came across the internet as plain text in a format called JSON — a format for sending nested data over the wire — looks like a Python dict and list combined.

If you have used dictionaries in Python (the { "key": "value" } thing), JSON will feel familiar. That is because JSON is basically a Python dictionary written down as text and sent through a wire. To turn that text back into a real Python dictionary you can use, you call .json() on the response:

import requests
 
response = requests.get("https://api.exchangerate.host/latest?base=USD")
data = response.json()
 
print(data)

Now data is a normal Python dictionary, the same shape you have been working with since Week 2. You can look up keys inside it the same way you always have.

Pulling one value out

The exchange rate API gives you back a dictionary that looks roughly like this:

{
    "base": "USD",
    "date": "2026-05-16",
    "rates": {
        "EUR": 0.91,
        "GBP": 0.78,
        "GHS": 12.43,
        "NGN": 1580.0
    }
}

There is a top-level key called rates, and inside it is another dictionary with currency codes. To get one value out, you walk in step by step:

import requests
 
response = requests.get("https://api.exchangerate.host/latest?base=USD")
data = response.json()
 
ghs_rate = data["rates"]["GHS"]
print("One US dollar is", ghs_rate, "Ghana cedis today.")

Read data["rates"]["GHS"] out loud: "from data, give me the rates jar; from that, give me the GHS jar." That is it. The data took a long trip across the internet to land in your notebook, but once it is there, it is just a dictionary like any other.

A small worked example you can run right now

Let's put the whole thing together. We will ask for the exchange rate, then print one neat line:

import requests
 
response = requests.get("https://api.exchangerate.host/latest?base=USD")
 
if response.status_code == 200:
    data = response.json()
    rate = data["rates"]["GHS"]
    print(f"Today, 1 USD = {rate} GHS")
else:
    print("Something went wrong. Status:", response.status_code)

Run that in a Colab cell. You will see a sentence with today's live exchange rate inside it. Run it again tomorrow and the number may be different, because the rate moves. Your program is now pulling fresh data from the world every time it runs. That is a real thing real programs do.

Rate limits and API keys — just so you've heard of them

Two things you will bump into eventually, but do not need to worry about today.

The first is rate limits. Most free APIs do not let you hammer them. If you call them a hundred times in one second, they will start refusing your requests for a while. The fix is usually to wait a moment between calls, or call them less often. The exchange rate API we used today is fine for our use, but keep this in mind once you start writing programs that loop.

The second is API keys. Some APIs do not let just anybody walk up — they want to know who you are. They give you a long string of letters and numbers called a key, and you include it with every request so they can recognise you. We are sticking to APIs that do not need a key today, but if you ever use one that does, the golden rule is: never paste your key directly into code you share, and never push it to GitHub. People run bots that scan for leaked keys.

Your exercise

Write a short program in a new Colab cell that does the following:

1. Calls the exchange rate API at https://api.exchangerate.host/latest?base=USD.
2. Checks that the status code is 200. If it is not, print a clear error message and stop.
3. Pulls out the rate for at least two currencies — say GHS and EUR.
4. Prints a small report like:

Today's rates against 1 USD:
GHS: 12.43
EUR: 0.91

If you finish early, ask the user for an amount in USD using input(), convert it to a number, and print how much that is in GHS using today's live rate.

Common slip-ups

These are the same three mistakes everyone makes the first time they call an API. When you hit one, you will recognise it from this list and fix it fast.

• Forgetting .json(). You call requests.get(...), you store the result in response, and then you try to do response["rates"] directly. Python complains, because response is not a dictionary yet — it is a response object with the data buried inside it. You must call response.json() first to turn it into a dictionary.
• Ignoring the status code. Your program looks fine, but the server returned 404 or 500, and you went straight to .json() anyway. Now you are reading values out of a dictionary that was never built correctly, and the error message you get five lines later will be confusing. Check response.status_code first. If it is not 200, stop and print what happened.
• Hardcoding tokens. The day you start using an API that needs a key, do not paste the key straight into your notebook and share the notebook. Use Colab's secrets feature or an environment variable. A key sitting in a shared file is a key that will be stolen.

That is the whole session. Run the exercise, take a screenshot of your program showing a live exchange rate, and bring questions to our next live session. Your code can now talk to the internet. From here, every public API in the world works the same way — you have just learned the pattern once.