How to Use APIs to Access AI Models

What an API Is (Without the Jargon)

Think of a drive-through window. You pull up, say your order in a specific format (“I’ll have a number 3, no pickles”), and you receive your food in a specific container. You don’t see the kitchen. You don’t know which cook made it. You just get output in response to your input.

An API (Application Programming Interface) works the same way. You send a request in a specific format, and you get a response back. You don’t see the model weights, the GPU cluster, or the inference code. You just send text in and receive text out.

AI APIs are drive-through windows to the world’s most powerful language models.

What “REST API” Actually Means

When developers say “REST API,” they mean a standardized way to make requests over the internet using HTTP - the same protocol your browser uses to load websites.

Every AI API call is fundamentally:

1. An HTTP POST request sent to a specific URL
2. A JSON payload in the request body (your prompt + settings)
3. An API key in the request headers (your authentication token)
4. A JSON response containing the model’s output

That’s it. Whether you’re calling OpenAI, Anthropic, or Google, this pattern is identical.

The Journey from Your Code to a Response

Here is exactly what happens in the roughly 1-3 seconds between your code sending a request and receiving a response:

flowchart TD
  A[Your Code] --> B[HTTP POST Request
JSON payload]
  B --> C[API Gateway
Auth + rate limiting]
  C --> D[Load Balancer
Route to GPU cluster]
  D --> E[GPU Inference
Tokens processed]
  E --> F[Response Stream
Tokens returned]
  F --> G[Your Code
Parsed JSON response]

  style A fill:#dbeafe,stroke:#2563eb,color:#1d4ed8
  style G fill:#dcfce7,stroke:#16a34a,color:#15803d
  style E fill:#f3e8ff,stroke:#7c3aed,color:#7c3aed
  style C fill:#fef3c7,stroke:#d97706,color:#b45309

Steps C and D are entirely managed by the API provider. You never interact with them directly. Your job is steps A and G: form the request, parse the response.

The Universal Request Structure

Every major AI API uses this same conceptual structure, regardless of provider:

{
  "model": "gpt-4o",
  "messages": [
    {
      "role": "system",
      "content": "You are a helpful assistant that summarizes documents concisely."
    },
    {
      "role": "user",
      "content": "Summarize the following in 3 bullet points: [your text here]"
    }
  ],
  "max_tokens": 500,
  "temperature": 0.7
}

What each field does:

• model - Which specific model to use (different models have different costs and capabilities)
• messages - An array of conversation turns. The system message sets the AI’s persona and rules. The user message is what you’re asking.
• max_tokens - Maximum length of the response. Prevents runaway costs and long waits.
• temperature - Randomness setting from 0 to 2. Near 0 = deterministic and focused. Near 1 = creative and varied. Use 0 for structured data extraction, 0.7 for writing, 0 for classification.

Provider Comparison

All three major providers expose a similar API surface. Here’s how they differ practically:

Your First API Call

Here is a complete, working Python example. It sends a system prompt and user message to OpenAI and prints the response.

import os
from openai import OpenAI

client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))

response = client.chat.completions.create(
  model="gpt-4o-mini",
  messages=[
      {"role": "system", "content": "You are a concise technical writer."},
      {"role": "user", "content": "Explain what an API is in 2 sentences."}
  ],
  max_tokens=150,
  temperature=0.5
)

print(response.choices[0].message.content)

Breaking down response.choices[0].message.content:

• response.choices - A list of possible completions. Usually just one.
• [0] - The first (and typically only) completion.
• .message.content - The actual text the model generated.

The response object also contains .usage.prompt_tokens and .usage.completion_tokens - use these to track costs.

What Happens When Things Go Wrong

API calls can fail. Common errors and what they mean:

Always wrap API calls in try/except blocks in production code.

What’s Next

Now that you can make an API call, the quality of your results depends almost entirely on what you put in the messages array. That’s prompt engineering - and it’s the subject of the next tutorial.

Interview Notes: API Controls and Reliability

Production API usage is more than sending a prompt. You should know the common controls:

import asyncio

async def call_with_retry(client, payload, attempts=3):
    for attempt in range(attempts):
        try:
            return await client.responses.create(**payload)
        except RateLimitError:
            if attempt == attempts - 1:
                raise
            await asyncio.sleep(2 ** attempt)

payload = {
    "model": "fast-model",
    "input": "Summarize this support ticket in JSON.",
    "temperature": 0.1,
    "top_p": 0.9,
}

Interview Practice

1. What fields should a basic AI API request include?
2. When would you use streaming instead of waiting for the full response?
3. How should a client handle rate limits and transient provider failures?
4. Compare temperature, top_p, top_k, and beam search.
5. When is batch processing better than synchronous API calls?
6. What metadata should you log for each model request?