Developer Round Table - Testing API Calls

This week during our Developer Round Table, Yossef shared some information with the group about API development he’d been doing recently for a client, along with some of the different tools a developer has available for testing an API and showcasing that testing to a client. He walked through curl, httpie, and Demo Magic (including his own wrapper around Demo Magic), based on real examples from the work he did.

When working with APIs, it’s important to be able to test the response to make sure the calls you’re making, and the data you’re retrieving, are what you want and need.

For example, if you have an application that displays the current weather in a specific location, you need to know that the call to that API is performing as expected and returning the data that you would like. Things like, temperature, location, time, humidity and rain probability percentage. To test this, you have a few different options available.

Curl

Curl is a command-line tool used to transfer data to or from a server. It works from any terminal and requires no install of a GUI app to test APIs. Within your command line, you can enter a command like the one below.

curl "https://api.open-meteo.com/v1/forecast?latitude=43.0731&longitude=-89.4012&current=temperature_2m,relative_humidity_2m,precipitation&hourly=precipitation_probability&temperature_unit=fahrenheit&timezone=America/Chicago"

You can actually try this now if you want, open-meteo is a free, open weather API. You can make calls to it without needing to pass in extra information like an API key. This will return a JSON response, which is raw text that is unformatted. It looks like the code below.

{"latitude":43.060394,"longitude":-89.39947,"generationtime_ms":0.06282329559326172,"utc_offset_seconds":-18000,"timezone":"America/Chicago","timezone_abbreviation":"GMT-5","elevation":272.0,"current_units":{"time":"iso8601","interval":"seconds","temperature_2m":"°F","relative_humidity_2m":"%","precipitation":"mm"},"current":{"time":"2026-08-12T12:15","interval":900,"temperature_2m":78.0,"relative_humidity_2m":84,"precipitation":0.00},"hourly_units":{"time":"iso8601","precipitation_probability":"%"} [hourly data that I ommitted for length reasons]

From this response, we can see the timezone, the temperature, humidity and precipitation. This is a very simple example of using curl. Often as software developers, we have more intensive constraints to deal with, like passing in authorization params and/or API keys. It might look a lot like this:

curl -X POST "https://api.example.com/v1/orders" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"item": "widget", "quantity": 3}'

Breaking that down:

• -X POST this is a write, not a read, so GET isn’t right anymore. We want POST
• -H "Authorization: Bearer ..." This proves who you are
• -H "Content-Type: application/json" This tells the server “the body I’m sending is JSON,” so it parses it correctly
• -d '{...}' this is the actual JSON body being sent

Depending on the needs of the application you are working on, using curl is going to look a lot like the above examples. Although curl is convenient to use, the response can be difficult to parse through and read. Additionally, if you have an error it can be difficult to understand where the error occurred and for what reason, unless you add even more arguments to the command line. Curl doesn’t fail on HTTP error codes by default, so scripts can silently treat failures as successes unless you add -f/--fail explicitly.

Httpie

Httpie is a command-line tool that does the same job as curl, sending requests to a server, but it’s built to be more human-friendly, both in how you type the command and how it shows you the response. Where curl mirrors the raw pieces of an HTTP request (flags, headers, a body string), httpie’s syntax reads more like the request itself.

Within your command line, you can enter something like

http https://api.open-meteo.com/v1/forecast latitude==43.0731 longitude==-89.4012 current==temperature_2m,relative_humidity_2m,precipitation temperature_unit==fahrenheit

Notice the query parameters aren’t crammed into one long URL string like they were with curl. Each one is just key==value, space-separated. Httpie builds the actual URL for you behind the scenes.

The response comes back the same JSON as before, but httpie pretty-prints and color codes it automatically (indented, keys sorted, syntax highlighted) without you having to do something like pipe it through jq yourself or suffering trying to decode with your eyes. It looks something like

{
    "current": {
        "precipitation": 0.0,
        "relative_humidity_2m": 84,
        "temperature_2m": 78.0,
        "time": "2026-08-12T12:15"
    },
    "latitude": 43.060394,
    "longitude": -89.39947
}

Way nicer to read and look at. Following the same examples as curl above, lets look at a more complex call to an API using httpie.

http https://api.example.com/v1/orders \
  "Authorization:Bearer YOUR_TOKEN" \
  item=widget \
  quantity:=3

Breaking that down:

• no POST because of the extra parameters, httpie infers you’re doing a write, so it will automatically send a POST instead of a GET. You can provide the method on the command if you want to be explicit, but you don’t have to.
• “Authorization:Bearer YOUR_TOKEN" - the colon (:) is httpie’s notation for a header, this proves who you are
• item=widget - the equals sign (=) means a plain string field, httpie serializes it into a JSON body for you and sets Content-Type: application/json automatically
• quantity:=3 - the colon-equals (:=) means “treat this as raw JSON,” so 3 stays a number instead of becoming the string "3"

The wonderful thing about using httpie vs curl is that it does a lot more for you in terms of readability. It’s building the JSON body, setting content-type headers, and formatting the response, which makes it easier to read and faster to type. It also defaults to showing the response headers, which carry very useful information. The one potential drawback is you will have to install httpie yourself unlike curl.

Demo Magic

Demo Magic is a bash script that lets you pre-script a live terminal demo so it looks like you’re typing in real time, without the risk of actually typing it live. Instead of you fat-fingering a command in front of an audience, you write the commands into a script ahead of time, and Demo Magic “types” them out on screen for you, character by character, before running them.

This can be super helpful when you are presenting at a conference or if you are demonstrating functionality to a client.

A demo script usually looks something like

#!/bin/bash

. demo-magic.sh

clear
pe "curl https://api.open-meteo.com/v1/forecast?latitude=43.0731&longitude=-89.4012&current=temperature_2m"
pe "http GET https://api.open-meteo.com/v1/forecast latitude==43.0731 longitude==-89.4012"

All you need to do is run ./demo.sh, and from there Demo Magic takes over, simulating the typing and waiting for a keypress before actually executing anything.

Lets dig into these commands a little more:

• . demo-magic.sh - this sources the Demo Magic functions into your script so pe, p, and others become available
• pe "command" - stands for “print and execute,” it simulates typing the command, pauses for a bit (or waits for you to hit enter, depending on what options you choose), and then actually runs it
• p "command" - “print only,” same fake-typing effect but it never actually executes, useful for commands you want to show without running (like something destructive, or something that needs a real network you don’t have on stage)
• there’s also pei, “print and execute immediately,” which skips the wait and just runs right through, handy for setup steps the audience doesn’t need to wait on

This, as you can tell, solves a pretty specific problem: typing a demo command live, in front of an audience, without the risk of a typo under pressure. The tradeoff is that it’s only useful for that presentation context. It’s not something you’d reach for in day-to-day development the way you would curl or httpie. But if you are meeting with a client and need to show off the work you have been doing, Demo Magic is a great tool to have.

Yossef’s Demo Wrapper

Yossef built his own wrapper around Demo Magic, in his dotfiles, which fixes a handful of rough edges and adds a few conveniences on top.

Using it looks like this:

#!/usr/bin/env bash
source "$(demo-lib)"

say "First, the orders that already exist"
hold
pe 'http GET :3000/orders'

say "Creating one takes a customer and a total" "Watch the location header"
hold
pe 'http POST :3000/orders customer=alice total=42'

To explain each line:

• say "..." - prints a dimmed narration line above the command, so you can talk through what you’re about to show before you show it
• hold - a manual pause between steps that waits for you, separate from the pause pe already gives you before it runs the command
• pe 'http GET :3000/orders' - the same pe from vanilla Demo Magic, still simulating the typing and running the real command

All the original Demo Magic flags still work on top of this (-d for no typing, -n for no waiting, -w N to auto-advance), plus one Yossef added himself: --unattended, which runs the whole demo start to finish with no typing and no pauses. That one’s less about presenting and more about confidence, letting you easily test your demo script before running it in front of an audience.

The rest of what’s in the repo is mostly Yossef fixing things vanilla Demo Magic gets wrong in small but annoying ways, like your typing speed or prompt settings getting silently reset the moment you source the script. None of it changes what the audience sees in a major way, but hopefully it means the person running the demo can trust it a little more.

Thanks to Yossef for sharing this with the group. Testing tools like these are the kind of thing that’s easy to overlook until you need them, and having options ready for both quick debugging and client-facing demos is a good habit to build. Looking forward to seeing what the next Developer Round Table brings!

If you’re looking for a team to help you discover the right thing to build and help you build it, get in touch.