AI APIs & Automation

API stands for application programming interface. Strip the jargon and it is simply a doorway that lets one program talk to another program directly, without a human clicking buttons in between. The AI you have been chatting with also has an API: the same model, reached not by typing into a web page but by a short piece of code that sends it your text and receives its reply.

A helpful analogy: the chat window is the dining room of a restaurant - pleasant, one order at a time, a waiter in the loop. The API is the kitchen's serving hatch - less charming, but you can send three hundred orders through it in the time it takes to seat one table. Same kitchen, same chef; different door, built for volume.

Mechanically, using an AI API means three things. You get an API key - a secret password that identifies your account and, importantly, is what you get billed against. Your code sends a request - your prompt, plus settings like which model to use. The service sends back a response - the model's answer, as data your script can then save, sort or feed into the next step of a pipeline (Module 8.1).

The key mental shift is this: through the API, the AI becomes a component you can build into a workflow, not just a place you visit. That is what unlocks scale. It is also what makes the honesty guardrails matter more, not less - an API call gives you no chat window to eyeball the answer in, so the checking has to be designed into the process deliberately.

Here is about as small as a real AI API call gets, in Python. Do not worry if you do not code - read it like a recipe. It sends one instruction to a model and prints the reply.

# A minimal AI API call (illustrative)
from anthropic import Anthropic

client = Anthropic()  # reads your secret API key from the environment

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=300,
    messages=[
        {"role": "user",
         "content": "Summarise this room brief in 3 bullet points: "
                    "a calm, warm bedroom for an elderly couple, "
                    "low maintenance, good natural light."},
    ],
)
print(response.content[0].text)

That is the whole shape of it: create a client, send a message naming the model and your prompt, read the reply. The real power comes when you wrap that call in a loop - the same three lines, run once for each item in a list:

for brief in all_room_briefs:      # e.g. 200 rooms
    reply = summarise(brief)        # one API call each
    save(reply)                     # collect the results

Now the same task that would take a full day of copy-paste runs while you make tea. Nothing about the prompt changed - the skill you built in earlier modules transfers directly; you are just delivering it through a different door, many times over. This is a deliberately light taste. Writing, running and debugging scripts like this is a craft of its own, and the companion Python & Scripting for Designers course teaches it properly, from the ground up.

An API is a power tool, and like any power tool it is overkill for small jobs and transformative for the right big ones. The honest test is volume times repetition. If you are doing something once, or a handful of times, stay in the chat window - it is faster, you see every answer, and there is nothing to set up. The moment a task is both repetitive and high-volume, the maths flips: the hour you spend writing a script is repaid many times over, and the machine does not get bored or sloppy on item 180 the way a human does.

Good candidates are tasks that are mechanical, numerous and tolerant of a review pass: batch-tagging an image library, extracting the same few fields from a stack of PDFs, generating alt-text for a whole photo set, standardising the wording across hundreds of schedule lines. Poor candidates are the one-offs, the genuinely judgement-heavy tasks, and - critically - anything high-stakes that you cannot realistically review at scale.

That last point deserves weight. Automation multiplies output, which means it also multiplies errors if you are not careful. A script that mislabels one image will happily mislabel all two hundred in the same wrong way. So automation does not remove the human gate; it moves it. Instead of checking each answer as it appears, you design verification into the batch: spot-check a random sample, add sanity rules that flag suspicious outputs, and never let an unreviewed batch flow straight into a deliverable. There is also a real cost dimension - every API call is billed, so a runaway loop is a runaway bill. Start tiny, on ten items, before you ever run three hundred.

There is one more shift worth internalising before you automate anything: at scale, you lose the free safety net the chat window gave you. In chat, you see every answer as it appears, so a hallucination or an off-key response is caught almost by reflex. Run the same prompt over three hundred items through an API and no human sees the individual answers - they land in a file all at once, looking equally tidy whether they are right or wrong.

That changes what 'checking' has to mean. You can no longer eyeball everything, so you build verification into the batch by design. Spot-check a random sample - read fifteen or twenty of the three hundred and judge the hit rate; if it is poor, fix the prompt and rerun rather than shipping. Add sanity rules - simple automatic flags for outputs that are obviously off: empty results, answers far too long or too short, a summary that never mentions the subject. Keep inputs and outputs together so you can trace any suspicious result back to what produced it. And never let an unreviewed batch flow straight into a deliverable - a client schedule, a published set - without a human pass over at least a sample.

Structured output helps here too. Asking the model to return its answer in a consistent, machine-readable shape - a table, or JSON with named fields - makes the results far easier to scan, sort and sanity-check than free-flowing prose, and makes it obvious when a field is missing. It is a small prompt-craft habit that pays off enormously the moment you are handling volume.

The theme is the one running through the whole module: automation does not retire your judgement, it relocates it - from watching each answer to designing how the batch gets checked.

You do not have to become a programmer to benefit from this - but you do get more out of the rest of AI-assisted design if the idea of an API stops feeling like a locked door. Here is a sane, low-risk path.

First, let AI write the script for you. This is one of the most practical uses of an LLM for a non-coder: describe the batch job in plain English - 'read every PDF in a folder, summarise each in three bullets, save to a spreadsheet' - and ask it to write the Python. You will still need to run it and, crucially, understand it well enough to check it, but the blank-page barrier largely disappears. The Python & Scripting for Designers course has a whole lesson on coding this way with AI assistants.

Second, respect the practicalities. An API key is a secret tied to real money - never paste it into a chat, commit it to shared code, or email it around; leak one and someone else runs up your bill. Watch usage, set spending limits where the provider offers them, and test on a handful of items before unleashing a full run.

Third, know where the line is for you. Plenty of excellent designers will never write an API call, and that is completely fine - the chat tools, prompt libraries and custom assistants from the last two lessons cover the vast majority of AI-assisted design. Think of the API as an optional next gear: worth knowing exists, worth reaching for when a genuinely repetitive high-volume job appears, and worth learning properly - through the Python course - only if that kind of work becomes a regular part of what you do.