API integration

5.1 Understanding APIs

An Application Programming Interface (API) is a set of protocols and tools that let different software applications communicate and share functionality. With an API, developers pull external services or data into their applications instead of building those services from scratch.

Why and when we use APIs. At their most general, APIs serve four overlapping purposes. They integrate services, letting separate systems work together: the weather app on your phone pulls forecast data from an external service through an API rather than running its own meteorological infrastructure. They extend functionality; a company that needs to accept payments plugs in Stripe or PayPal rather than writing a payment processor. They enable automation and efficiency by letting applications talk to each other without a human in the loop, as when a CRM and an email marketing platform synchronize customer records on a schedule. And they standardize data sharing, giving applications a predictable way to expose data to each other, which makes it far easier to build tools that depend on external or internal datasets.

Why APIs are needed in a company context. Inside an organization, APIs streamline operations by connecting internal systems such as HR, CRM, and inventory management so that workflows stay consistent across tools. They support scaling and innovation by giving the business access to third-party AI services, analytics platforms, and cloud computing resources without long build cycles. They strengthen customer experience, since chat support, location services, and payment processing inside customer-facing applications all run on them. And they enable cross-team collaboration in large organizations: departments share services instead of duplicating work in parallel silos.

Why APIs are useful in a personal context. For individuals, APIs simplify daily tasks by letting personal applications tap into weather forecasts, navigation, and financial tracking. They support customization and automation through platforms like IFTTT and Zapier, which let users wire up workflows between their favorite apps without writing code. And they are invaluable for learning and experimentation: students, developers, and hobbyists get a low-friction way to build projects, reach external services, and pick up programming skills along the way.

5.2 Implementation steps

Implementing an API follows the same arc regardless of provider. It starts with understanding requirements: define the functionality you need and identify APIs that supply it. Then comes accessing documentation to learn the API's capabilities, endpoints, authentication methods, and usage limits. Once the right service is selected, the team obtains access credentials by registering with the provider for the API keys or tokens that authenticate the application's requests. From there the engineering work is to integrate the API, writing code that sends requests to the relevant endpoints and handles the responses, and finally to run testing and monitoring so the integration behaves in production and performance regressions get caught early.

Tutorial

Getting started with the OpenAI API in particular is a six-step exercise. Sign up or log in on OpenAI's website, then navigate to the API section to review the documentation on usage, pricing, and capabilities. Generate an API key from the dashboard's API Keys section so your application can authenticate, and choose a pricing plan that fits your expected usage. OpenAI offers pay-as-you-go pricing with model-specific rates. Test the API using Postman or OpenAI's Playground, supplying your key in the request headers. Once everything responds as expected, integrate it into your application using the key and endpoints described in the documentation.

What a Real API Call Looks Like

Executives do not need to write this code, but they should recognize its anatomy, because every GenAI feature in every product reduces to some version of these ten lines (Python, using Anthropic's SDK; OpenAI's is nearly identical):

import anthropic
client = anthropic.Anthropic() # reads ANTHROPIC_API_KEY from the environment
response = client.messages.create(
  model="claude-sonnet-5",
  max_tokens=1024,
  system="You are a support assistant. Answer only from the provided policy.",
  messages=[{"role": "user", "content": "A customer asks: " + ticket_text}]
)
print(response.content[0].text)

Five things in that snippet carry the management lessons. The API key lives in the environment, never in the code, because a leaked key is a leaked budget (and, under some agreements, leaked data access); key management and rotation is the first governance control on any AI project. The model is a string, which is why model routing (Section 5.3) is a one-line change and vendor lock-in is weaker than procurement fears suggest. The system prompt is where your policies live, and it is exactly the surface prompt injection attacks target (Chapter 3). The messages array is the conversation memory: the API is stateless, so your application decides what history to send each time, which is context engineering in practice. And max_tokens is a spending cap per call, your first cost control.

Four capabilities turn this toy into a production integration. Structured output: instructing the model to reply in a defined JSON schema ("return {category, urgency, suggested_reply}") so software, not humans, consumes the result reliably. Tool use (function calling): registering functions the model may call, "look up order status," "create a ticket", so it can act, not just write; this is the mechanism beneath every agent in Chapter 7, and the Model Context Protocol (MCP) standardizes it across vendors. Streaming: returning tokens as they generate, which turns a ten-second wait into an immediately flowing answer and matters enormously for user-facing products. And error handling: real integrations expect rate limits, timeouts, and occasional malformed outputs, and retry with backoff rather than failing, which is harness engineering (Chapter 3.4) at its most basic.

5.3 Pricing and strategy

LLM API pricing is metered by tokens, the word-fragments models read and write, with separate rates for input (your prompt and context) and output (the model's response), and output typically costing three to five times more. Providers layer three pricing structures on top: pure pay-as-you-go per-token billing (the default for OpenAI, Anthropic, and Google APIs); committed-use and enterprise agreements that trade volume commitments for discounts, private networking, and data-handling terms; and flat subscription seats for chat products (ChatGPT, Claude, Gemini plans), which are priced per user rather than per token and are the right economics for individual daily use but not for applications. The first budgeting instinct to build: estimate tokens per task, tasks per month, and multiply, because "it's only cents per call" quietly becomes real money at one hundred thousand calls.

Printed price tables age in weeks, so this section gives you the shape of the market and the habit of checking, rather than numbers to memorize. As of mid-2026, closed frontier flagships (the top Claude and GPT tiers) cost on the order of $5–$10 per million input tokens and $25–$50 per million output tokens; the mid-tier workhorses most applications should default to (the middle Claude, GPT, and Gemini tiers) run roughly $1–$3 in and $10–$15 out; the small fast tiers each provider offers sit near $1 in and $5 out; and open-weight models served by hosting providers can undercut all of these by an order of magnitude. Two ratios are more durable than any absolute number: output tokens cost three to five times input tokens, and each tier down typically cuts cost three- to five-fold, which is why the routing strategies below matter more than the list price. For live, independently maintained comparisons, check Artificial Analysis (https://artificialanalysis.ai/) and the provider pricing pages before any budgeting exercise.

Just as important as what you pay is where you buy. There are three procurement routes. Direct APIs from the model makers offer the newest models first and the best documentation. Cloud marketplaces, AWS Bedrock, Microsoft Azure (Foundry), and Google Cloud Vertex AI, serve the same frontier models inside your existing cloud contract, which brings enterprise essentials that matter more than price for regulated buyers: consolidated billing and committed-spend discounts, private networking so prompts never cross the public internet, and, critically, region pinning, so a European company can run Claude or GPT entirely within EU data centers. Aggregators such as OpenRouter put hundreds of models, closed and open-weight, behind one API key with automatic fallbacks, which is the fastest way to A/B test models and a useful hedge against single-vendor outages; its public usage rankings double as a live census of what developers actually choose.

For European readers, and anyone serving European customers, GDPR shapes this choice directly. The questions to resolve before a single customer record touches an API: Is there a data processing agreement (DPA) with the provider, and standard contractual clauses if data leaves the EU? Is API data excluded from model training (the default for the major providers' business tiers, but verify it in writing, and note that consumer chat apps often work differently)? Can you enforce EU data residency, which in practice usually means the cloud-marketplace route? And what are the retention terms, since zero-data-retention options exist for sensitive workloads? None of this is exotic: the same diligence you apply to any cloud processor applies here, plus the AI-specific obligations Chapter 13 details. The practical pattern for a GDPR-conscious rollout is common and sensible: prototype on direct APIs with synthetic or anonymized data, then move to Bedrock or Azure in an EU region for production.

Three cost levers matter more than the sticker price, and they are where practitioners actually save money. Prompt caching discounts repeated input (system prompts, reference documents) by up to 90% on cached reads, which transforms the economics of agents that carry a large, stable context. Batch processing typically halves the price of work that can wait a few hours, such as overnight document processing. And model routing, sending easy queries to a cheap tier and hard ones to the flagship, routinely cuts blended costs by 50 to 80% with little quality loss. When you evaluate a vendor's "cost per query" claim, ask which of these levers it assumes.

5.4 Applications across domains

Where do GenAI APIs actually earn their keep? In web development, they generate dynamic content: personalized recommendations, automated customer support chatbots, real-time language translation. They can also draft tailored web copy or UI designs, which shortens the build.

In mobile applications, they power voice-to-text conversion, AI-driven virtual assistants, and content creation tools that adapt to user preferences. An app can generate text summaries, personalized messages, or interactive narratives on the fly.

In data analysis, they turn complex data into human-readable narratives, generate automated insights, and even create visualizations from raw datasets. A business can understand its data and communicate findings without hours of manual interpretation.

In the Internet of Things (IoT), they add contextual insight and predictive suggestions to device communication. An IoT system managing energy consumption, for example, could use a generative AI API to write detailed, customized reports for users or suggest actions to cut waste.

The business payoff is most visible in two areas: customer support and content creation.

Consider a company trying to improve its customer support. By integrating a generative AI API, it can build a chatbot that handles a broad range of inquiries. Unlike a rule-based bot, the generative system understands nuanced language, gives contextually accurate responses, and can even manage a passable imitation of empathy. If a customer asks about a shipment, the AI pulls the latest tracking data from backend systems and reports it in plain language. When it hits a genuinely hard problem, it escalates to a human agent with a detailed summary attached, so the handoff is smooth and resolution times drop. Customers are happier, and the human agents spend their day on the cases that actually need them.

In a personal context, the same APIs change how creative work gets done. Take a freelance writer producing blog posts on diverse topics against tight deadlines. With a generative AI API, she can generate outlines or full drafts from a simple prompt and spend her time refining and personalizing the material instead of staring at a blank page. Delivery speeds up without the output dropping below professional standards. The AI can also match specific tones or styles, so one writer can serve clients with very different voices.

5.5 Evals and Observability: The Difference Between a Demo and a Deployment

Here is the uncomfortable truth about API integration: the code above is a demo. What makes it a deployment is everything wrapped around it that tells you, continuously, whether it is working. The discipline has a name, evals, and Chapter 3 introduced the minimal version: a golden set of real examples with known good outputs, a pass/fail rubric, and the habit of running every change against the set before shipping it. At the API integration layer, three practices complete the picture.

First, regression-test model upgrades like software releases. Providers retire and replace models on a cadence of months; each swap changes behavior in ways release notes never fully describe. Teams with an eval suite treat a model upgrade as a one-day exercise, run the suite, compare, fix the three prompts that regressed. Teams without one discover the regressions from customers. Ironically, the first edition of this book aged the same way its stale model tables did: version churn is not an edge case, it is the operating environment.

Second, log every call. Inputs, outputs, model version, token counts, latency, and the downstream outcome (did the human accept the draft? did the customer escalate?). This telemetry is what makes evals improvable, costs attributable, and incidents diagnosable, and it is also your evidence trail for the governance obligations in Chapter 13. Purpose-built LLM observability tools exist, but a disciplined log table is 80% of the value.

Third, use LLM-as-judge with human audit. For subjective qualities (tone, helpfulness, brand fit), a second model grading outputs against your rubric scales to volumes humans cannot, and a weekly human audit of a sample keeps the judge honest. The pattern to remember, and to require from vendors, mirrors the loop-engineering rule from Chapter 3: the system that produces the work must not be the only system that grades it.