API Integration: OpenAI, Anthropic, Open Source

What Is an API, Really?

Before we dive into AI-specific APIs, let's make sure the basics are crystal clear. An API (Application Programming Interface) is simply a way for your application to talk to another service. Think of it like ordering at a restaurant: you (the app) give the waiter (the API) your order (a request), and the kitchen (the AI provider's servers) prepares your meal and sends it back.

With AI APIs, the conversation looks like this: your app sends some text to a provider like OpenAI or Anthropic, their powerful AI models process it, and they send back a response. You never need to build or run the AI model yourself — you just pay for each request, like paying per meal.

How AI APIs Work

Every AI API call follows the same basic pattern:

1. You send a request containing your prompt (the text you want the AI to process), which model you want to use, and any settings like temperature (how creative vs. focused the response should be).
2. The provider processes it on their servers using their AI model.
3. You get a response with the AI's output, plus metadata like how many tokens were used (which determines your cost).

That's it. The complexity comes in choosing the right provider, handling things that go wrong, and managing costs — which is what the rest of this module covers.

Choosing Your AI Provider

There are three main approaches, each with distinct tradeoffs.

OpenAI (GPT-4, GPT-4o, GPT-3.5)

OpenAI is the most widely used provider and has the largest ecosystem of tools and tutorials. GPT-4o is their flagship model — fast, capable, and good at most tasks. GPT-3.5 Turbo is significantly cheaper and still handles simpler tasks well. Choose OpenAI when you want the broadest community support, extensive documentation, and a battle-tested platform.

Anthropic (Claude)

Claude excels at long documents, careful analysis, and tasks where safety matters. It can process very large context windows (up to 200K tokens), meaning you can feed it entire books or codebases at once. Claude also tends to be more cautious about harmful content. Choose Anthropic when you need to work with long documents, want thoughtful analysis, or prioritise safety.

Open Source (Llama, Mistral)

Open-source models can be self-hosted, which means you control your data completely and avoid per-request API costs. The tradeoff is that you need infrastructure to run them, and they typically aren't as capable as the top commercial models. Choose open source when data privacy is critical, you have the engineering team to manage infrastructure, or you want to avoid vendor lock-in.

API Keys and Authentication

Every provider requires an API key — a unique string that identifies your application and lets the provider bill you. Think of it as your account number at the restaurant.

Critical security rules:

• Never put API keys directly in your code. Store them in environment variables.
• Never commit API keys to Git. Add your .env file to .gitignore.
• Use different keys for development and production so a leaked dev key doesn't affect your live app.

Here's the right way to set this up:

import os
from openai import OpenAI

# Load key from environment variable, not hardcoded
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello, how are you?"}]
)

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

Estimating Costs

AI APIs charge by the token. A token is roughly three-quarters of a word in English, so a 1,000-word document is roughly 1,300 tokens.

Here's how to estimate monthly costs:

1. Estimate requests per day. How many users will trigger AI features, and how often?
2. Estimate tokens per request. Add up your prompt (input tokens) plus the expected response length (output tokens).
3. Multiply by price per token. Check the provider's pricing page for your chosen model.
4. Multiply by 30 days.

Quick example: If your app makes 10,000 API calls per day, each using about 1,000 input tokens and 500 output tokens with GPT-4o, that might cost several hundred dollars per month. Switch to GPT-3.5 Turbo for simpler tasks, and the same volume could cost ten to twenty times less.

Always start with a usage cap or budget alert so you don't get surprised by a bill.

Rate Limits

Every provider limits how many requests you can make per minute or per day. Hit the limit, and your requests get rejected. This is like a restaurant saying "we can only serve 50 tables per hour."

How to handle rate limits:

• Implement exponential backoff: if a request fails, wait 1 second, then 2, then 4, and try again.
• Queue requests instead of firing them all at once.
• Cache responses for common queries so you make fewer API calls overall.
• If you need higher limits, most providers offer increased tiers as your usage grows.

Error Handling Basics

In production, things will go wrong. The provider might be temporarily down, your request might be malformed, or you might hit a rate limit. Your app needs to handle all of these gracefully.

Essential error handling patterns:

import time
from openai import OpenAI, RateLimitError, APIError

client = OpenAI()

def call_ai_with_retry(prompt, max_retries=3):
    for attempt in range(max_retries):
        try:
            response = client.chat.completions.create(
                model="gpt-4o",
                messages=[{"role": "user", "content": prompt}],
                timeout=30
            )
            return response.choices[0].message.content
        except RateLimitError:
            wait_time = 2 ** attempt  # 1s, 2s, 4s
            time.sleep(wait_time)
        except APIError as e:
            if attempt == max_retries - 1:
                return "Sorry, this feature is temporarily unavailable."
            time.sleep(1)
    return "Sorry, please try again later."

The key principles: always set timeouts (don't let a single request hang forever), always retry with backoff (temporary failures are common), and always have a fallback message (never show raw error messages to users).

Building a Fallback Strategy

Don't rely on a single provider. If OpenAI goes down, your entire product shouldn't break. A simple fallback strategy looks like this: try your primary provider first, and if it fails after retries, switch to a backup provider. Many teams use OpenAI as primary and Anthropic (or vice versa) as backup. For simpler tasks, you might fall back to a cheaper model that's "good enough" rather than returning an error to the user.