Working With APIs

Here is an analogy that makes APIs click for most people. Imagine you are at a restaurant. You do not walk into the kitchen, grab ingredients, and cook your own food. Instead, you talk to a waiter. You tell the waiter what you want. The waiter takes that to the kitchen, the kitchen produces the meal, and the waiter brings it back to your table. You never see the kitchen. You do not need to know how the stove works.

An API (Application Programming Interface) is the waiter in this analogy. It is the mechanism that lets one piece of software talk to another without either needing to know the other's internal details. You send a request through the API, the other system does its thing, and the API brings back the response.

Every major app you use is built on APIs. When your weather app shows you the forecast, it called a weather data API. When you log into a website using your Google account, that is an OAuth API. When you pay for something online, a payment processing API handled the transaction. APIs are how the modern software ecosystem is connected.

For AI specifically: every AI model you have ever chatted with has an API. The chat interface you see at chat.openai.com or claude.ai is a polished frontend that talks to the same underlying API you can access directly. When you use AI through a no-code automation tool, that tool is calling the API behind the scenes.

Understanding APIs does not require you to become a developer. But it does require you to understand a handful of concepts: endpoints, HTTP methods, headers, and authentication. These concepts sound technical, but they are simpler than they appear.

Most AI APIs, and most web APIs in general, follow a style called REST (Representational State Transfer). REST is not a technology, it is a set of conventions that makes APIs predictable and consistent. Once you understand REST, you can read documentation for any REST API and understand what it is asking of you.

Endpoints are specific addresses you send requests to. They look like URLs. For example, the OpenAI chat completions endpoint is https://api.openai.com/v1/chat/completions. The Anthropic messages endpoint is https://api.anthropic.com/v1/messages. Each endpoint represents a specific capability or resource. Different endpoints do different things.

HTTP Methods describe what you want to do with a resource. The four most common are GET (retrieve something), POST (send something new or trigger an action), PUT (replace something), and DELETE (remove something). For most AI API calls, you will use POST, as you are sending your prompt to the model and asking it to generate a response.

Request body is the data you send along with your request. For a POST request to an LLM API, the body typically contains: the model you want to use, the messages in the conversation (each message has a role and content), and any parameters like temperature or maximum response length. This is usually written in JSON format, a structured text format that uses key-value pairs.

The response is what comes back. For a successful API call, the response includes a status code (200 means success, 4xx means you made an error, 5xx means something went wrong on their end) and a response body containing more JSON with the model's generated text and metadata like how many tokens were used.

Here is what a simplified LLM API request looks like in plain terms: "Hey OpenAI, send a POST to your chat completions endpoint. I want to use gpt-4o. Here is the conversation so far: one system message setting the AI's role, and one user message containing my question. Respond in JSON with the generated reply."

That is the entire model. Everything else is filling in the details.

APIs are not public free-for-alls. To use an AI API, you need to prove who you are and that you are authorized to make requests. The standard mechanism for this is an API key: a long, randomly generated string of characters that uniquely identifies your account.

When you sign up for OpenAI, Anthropic, or Google AI Studio and navigate to the API section, you generate an API key. It looks something like this (illustrative, not real): sk-abc123XYZ789defghijklmnopqrstuvwxyz...

You include this key in every request you make to the API, typically in the Authorization header, a piece of metadata attached to your request that says "this request is authorized by the account holding this key." The exact syntax varies slightly by provider. OpenAI uses Authorization: Bearer sk-your-key. Anthropic uses x-api-key: sk-your-key. Google uses different OAuth flows depending on the product.

API keys are sensitive. They are tied directly to your billing account. If someone else gets your key, they can make API calls that get charged to you. They could also impersonate your application. This is why key management is critical.

The cardinal rules of API key security: never paste your key into a public chat, forum, or document. Never commit it to a code repository where it might become public. Never hard-code it directly in a web application that runs in the browser, where users can inspect the source. Store it in environment variables or secret management tools.

For no-code tools, this is straightforward: you paste the key into the credentials section of Zapier, Make, or n8n. These platforms handle storage and injection securely. For anything code-based, use a .env file and a library that loads it, and make sure your .env file is in your .gitignore.

If you think your key has been exposed, rotate it immediately. Every provider has a dashboard where you can revoke the old key and generate a new one. Treat this the same way you would treat a lost credit card and act fast.

The three major LLM API providers each have slightly different interfaces, but the conceptual model is the same across all of them. Here is what you need to know to get started with each.

OpenAI uses a messages array format. Each message has a role (either system, user, or assistant) and content (the text). The system message sets up instructions for the whole conversation. User and assistant messages alternate to represent the conversation history. The key parameters are model (e.g., gpt-4o), messages, temperature, and max_tokens. Responses come back in a choices array, and the generated text is at choices[0].message.content.

Anthropic (Claude) uses a similar but distinct structure. It also uses a messages array, but the system prompt is a separate top-level field rather than a message role. The required parameters are model (e.g., claude-opus-4-5), max_tokens, messages, and optionally system. Responses contain the generated text in content[0].text.

Google (Gemini) uses the Google AI SDK or REST API through Google AI Studio. The structure differs more significantly. Google uses a contents array with parts, and role labels are user and model rather than user and assistant. The documentation at ai.google.dev is the best starting point.

Beyond the big three, two services are worth knowing about. OpenRouter acts as a unified API gateway: a single API endpoint that lets you access models from OpenAI, Anthropic, Google, Meta, Mistral, and dozens of other providers. You get one API key, one request format, and the ability to switch between models by changing a single parameter. This is valuable for comparing models, building fallback chains, and optimizing costs by routing requests to the cheapest capable model. Hugging Face is the central hub for open-source AI models. It hosts thousands of models you can run for free (or cheaply via their Inference API), along with datasets, documentation, and community resources. If you want to experiment beyond the major commercial providers, Hugging Face is where to start.

For most Architect-level work, you do not need to memorize these API structures. You need to understand that they exist, how to read the provider's documentation, and how to set them up in your tool of choice. Every major automation platform (Zapier, Make, n8n) has a pre-built OpenAI or Anthropic action that handles the request structure for you. Just fill in the model name, paste in your prompt, and map the output.

If you are working with code, modern AI-powered editors make API work much faster. Cursor, GitHub Copilot, and Claude Code can generate API call boilerplate, debug response parsing, and explain unfamiliar API structures as you work. You do not need to memorize request formats when your coding environment can generate them for you.

If you prefer a visual approach without code, tools like Postman or Insomnia provide an interface for composing and sending HTTP requests. You fill in the endpoint, add your headers, paste in your JSON body, and hit send. This is useful for testing and debugging before you wire anything up in an automation.

Two practical realities of working with AI APIs that can surprise people: they have rate limits that can stop your workflow unexpectedly, and they have usage-based pricing that adds up quickly if you are not paying attention.

Rate limits are restrictions on how many requests you can make in a given time window, usually measured in requests per minute, tokens per minute, and requests per day. These limits exist to protect providers from runaway usage and to ensure fair access across their customer base. New accounts typically start with conservative limits and can apply for higher tiers as they demonstrate responsible usage.

In practice, hitting a rate limit means the API returns an error code (usually 429, Too Many Requests) rather than a response. If you build an automation that fires many requests simultaneously or in rapid succession, you will hit limits faster than you expect. The solutions are: add delays between requests, process work in batches, implement retry logic that waits and tries again when a 429 arrives, or apply for a higher rate limit tier through the provider's dashboard.

Pricing for LLM APIs is almost universally token-based: you pay per unit of text processed. Input tokens (your prompt) and output tokens (the model's response) are both charged, often at different rates. Pricing changes over time as providers compete and improve efficiency, so always check the current pricing page for any model before building something at scale.

The mental model for estimating costs: roughly 750 words is about 1,000 tokens. A short prompt plus a short response might use 500 tokens total. A long document analysis with a detailed output might use 8,000 tokens. Multiply by the per-token rate and by the number of times your workflow runs per month.

Practical advice: set a spending limit in the API provider's dashboard from day one. Both OpenAI and Anthropic allow you to set a maximum monthly spend that will cut off API access before charges exceed your limit. This is not optional. It is a safeguard against configuration errors, infinite loops, or a workflow that triggers far more than you expected.

Also watch your context window usage. Long system prompts and long conversation histories cost more per call because you are sending more tokens. For production workflows, keep your system prompts lean and do not pass unnecessary conversation history. Only include what the model actually needs for the current task.

Here is the practical reality for most Architect-level practitioners: you will call AI APIs from no-code tools far more often than you will call them directly from code. Understanding the conceptual model (endpoints, authentication, request body, response parsing) matters precisely because it lets you use these tools more effectively. You understand what they are doing, which makes you better at configuring them and debugging them when something goes wrong.

In Zapier, you have two options. The cleanest is using a native AI action. Zapier has built-in actions for OpenAI, Anthropic, and other providers. You select the action, enter your API key in the authentication step, pick the model, and write your prompt. The response text is automatically available as a variable for subsequent steps. Alternatively, Zapier's "Webhooks" action lets you make a raw HTTP request to any API, where you configure the endpoint, method, headers, and body manually.

In Make, the pattern is similar. Use the OpenAI or HTTP module. The HTTP module is the more flexible option, letting you call any API endpoint with full control over headers and body. You build the JSON body using Make's data mapping tools, where you can mix static text with dynamic variables from earlier in the workflow.

In n8n, the HTTP Request node is your universal API tool. You enter the URL, method, and body, and you can authenticate using stored credentials. n8n also has dedicated nodes for OpenAI that abstract the HTTP details away. Because n8n is open-source, the community has built nodes for dozens of AI providers and tools.

One pattern worth building early: a reusable "AI Call" module that wraps your prompt template, API key, and response parsing into a single unit you can drop into any workflow. In Make, this is a scenario fragment. In n8n, it is a sub-workflow. In Zapier, it is a Zap you trigger via webhook from other Zaps. This modular approach means you change your prompt or model in one place and every workflow that uses it updates automatically.

The path forward from here is hands-on. Pick one AI API provider, get a key, and connect it to one of the automation platforms. The first workflow will feel unfamiliar. By the third, you will be moving quickly. The concepts from this module (endpoints, authentication, request structure, rate limits) will become second nature through practice faster than through any amount of reading.