hibranwar
Course → Module 3: Web Interface vs API: The Professional Divide
Session 4 of 7

The API Landscape: Principles That Apply Everywhere

Session 3.4 · ~5 min read

Claude, Gemini, GPT, DeepSeek, Mistral. The names change. New models launch every few months. If you learn one API's quirks and build everything around its specific implementation, you are fragile. If you learn the shared architecture that all of them use, you are portable.

Every major LLM API follows the same fundamental pattern. Learn it once, and switching providers becomes a configuration change, not a rebuilding project.

The Universal Architecture

Every LLM API consists of four components: authentication, endpoints, parameters, and structured responses. The specifics differ between providers, but the concepts are identical.

graph LR A["Authentication
(API Key)"] --> B["Endpoint
(URL)"] B --> C["Parameters
(model, temperature,
max tokens, messages)"] C --> D["Structured Response
(JSON with content,
usage, metadata)"] style A fill:#2a2a28,stroke:#c8a882,color:#ede9e3 style B fill:#2a2a28,stroke:#6b8f71,color:#ede9e3 style C fill:#2a2a28,stroke:#8a8478,color:#ede9e3 style D fill:#2a2a28,stroke:#c47a5a,color:#ede9e3

Component 1: Authentication

Every API requires proof that you are allowed to use it. This proof is an API key, a long string of characters that acts as both your identity and your password. You include it in every request, typically in the HTTP header. The provider uses it to identify your account, track your usage, and bill you.

All major providers use the same pattern: you create an account, generate an API key in your dashboard, and store it securely in your environment (never in your code). The key goes in the Authorization header of every request.

Component 2: Endpoints

An endpoint is a URL you send your request to. Each provider has a main endpoint for text generation. The URL differs, but what you send to it and what you get back follows the same structure.

Provider Text Generation Endpoint Auth Header Format
Anthropic (Claude) api.anthropic.com/v1/messages x-api-key: YOUR_KEY
OpenAI (GPT) api.openai.com/v1/chat/completions Authorization: Bearer YOUR_KEY
Google (Gemini) generativelanguage.googleapis.com/v1beta/models/... API key in URL parameter or OAuth
DeepSeek api.deepseek.com/v1/chat/completions Authorization: Bearer YOUR_KEY
Mistral api.mistral.ai/v1/chat/completions Authorization: Bearer YOUR_KEY

Notice the pattern. Most providers adopted OpenAI's endpoint format (/v1/chat/completions) because it became the de facto standard. Anthropic chose a different path (/v1/messages), but the concept is identical: send a POST request to this URL with your prompt and parameters.

Component 3: Parameters

Every text generation request includes the same core parameters, even if the field names vary slightly between providers.

Concept What It Controls Typical Range
Model Which model processes your request Provider-specific string (e.g., "claude-sonnet-4-20250514")
System prompt Persistent instructions for the model Free text, any length within context window
Messages The conversation: user messages and assistant responses Array of role/content pairs
Temperature Randomness of output (low = predictable, high = creative) 0.0 to 1.0 (some allow up to 2.0)
Max tokens Maximum length of the response 1 to model's output limit
Top-p Nucleus sampling threshold 0.0 to 1.0

The parameters are the same everywhere. Model selection, system prompt, messages, temperature, max tokens. Learn what each one does once, and you understand every provider's API.

Component 4: Structured Responses

Every provider returns a JSON object containing the generated text, usage statistics (input tokens, output tokens), and metadata (model version, stop reason). The field names differ, but the information is the same.

A response always tells you: what the model generated, how many tokens it consumed (for billing), why it stopped generating (hit the token limit, finished naturally, or was filtered), and which model version processed the request.

The Portability Principle

Because all providers share this architecture, you can abstract your code to be provider-agnostic. Write a function called generate_text() that accepts a system prompt, user prompt, and parameters. Inside that function, the API call goes to whichever provider you choose. Change the provider, change one function. The rest of your pipeline does not care which model generated the text.

graph TD A["Your Pipeline Code"] --> B["generate_text() function"] B --> C{"Which provider?"} C -->|"Config: anthropic"| D["Claude API call"] C -->|"Config: openai"| E["OpenAI API call"] C -->|"Config: google"| F["Gemini API call"] D --> G["Standardized response"] E --> G F --> G G --> H["Rest of your pipeline"] style B fill:#2a2a28,stroke:#c8a882,color:#ede9e3 style G fill:#2a2a28,stroke:#6b8f71,color:#ede9e3

This portability is not just theoretical convenience. Model pricing changes. New models outperform old ones. Providers have outages. If your pipeline can switch providers by changing a configuration variable, you are resilient. If your pipeline is hardcoded to one provider, you are dependent.

Further Reading

Assignment

  1. Visit the documentation pages for at least two of these APIs: Claude API, Gemini API, and OpenAI API.
  2. For each, find and document: (1) Authentication method, (2) Main text generation endpoint URL, (3) Available parameters and their names, (4) Response format and key fields.
  3. Create a comparison table showing the similarities and differences. Notice how much is shared across providers. The shared elements are the concepts you need to learn. The differences are just syntax.