AI Agent Engineer

AI Agent Engineer
PERSONAL PROGRESS

Mark this course

Course content is public. Sign in to save personal progress.

LLM API Integration Learning Path

6 min read

LLM API Integration

Source review date: 2026-07-22. Endpoints, SDK methods, authentication, default retries, model identifiers, event types, rate limits, storage defaults, and pricing can change. This course teaches stable integration boundaries and fixes an auditable contract baseline for three providers. Real integrations must still follow the pinned official documentation, SDK version, machine schema, and live integration tests.

Course overview

LLM API integration brings prompts, context, and tool calls into running software. An introductory example often consists of one request, while a production system must also handle authentication, layered timeouts, a single retry budget, rate limits, structured outputs, in-stream failures, usage, logs, privacy, and provider differences. This course practices at two layers: first, a provider-neutral offline client contract teaches reliability responsibilities; then it separately parses the current Reference/SDK event projections and continuation contracts for OpenAI Responses, Anthropic Messages, and Gemini Interactions v1. Canonical events belong only to the first layer. The second layer does not force the providers’ identity, terminal-state, storage, or replay semantics into a single abstraction, and it does not present offline fixtures as real SSE bytes or live conformance.

Place in the overall learning path

This course is the engineering outlet for LLM application fundamentals. Modern LLM Capabilities and Model Selection provides candidate and task-level acceptance contracts; Prompt Engineering provides task and output contracts; Context Engineering provides evidence and state. This course owns reliable transport, parsing, observability, and error control. Tool Calling, RAG, agent frameworks, and LLMOps all depend on these foundations.

Learning goals

  • Build a minimal Python environment with venv + pip in Windows 11 / PowerShell 7, and read secrets safely.
  • Understand the responsibility boundary among HTTP, official SDKs, and application adapters.
  • Construct version-traceable messages, model configuration, and request metadata.
  • Correctly handle structured outputs, SSE streaming events, refusals, truncation, and mid-stream errors.
  • Design bounded, jittered retries for temporary failures such as timeouts, 429s, connection failures, and 5xxs; do not retry permanent errors.
  • Record request IDs, prompt versions, usage, latency, and outcome states while protecting sensitive content.
  • Use a stable operation_id to correlate attempts for one business operation, and separate model generation from external side effects.
  • Explicitly reject provider features that cannot be mapped equivalently through a capability check.
  • Handle Responses Items/calls, Messages blocks/tool-use, and Interactions steps/interactions separately for identity and terminal state; do not infer associations from array position.
  • Distinguish stateful handles, stateless replay, provider storage/retention, owned logs, and durable business state; do not mistake store=false for end-to-end non-retention.
  • Distinguish Platform API keys, workload short-lived tokens, and ChatGPT/Codex OAuth; do not conflate identically named models, authentication, actual backends, and agent runtimes.
  • Understand the respective proof boundaries of fixture contract tests, SDK integration tests, live model evaluation, and production audit.

Prerequisites

  • Basic Python functions, classes, exceptions, and JSON.
  • Basic HTTP request/response, status-code, and environment-variable concepts.
  • Prompt and context engineering are helpful prerequisites, but can be filled in while learning.
  1. Environment, Dependencies, and Secret Management: build a reproducible local environment without exposing secrets.
  2. HTTP, SDKs, and the Request Lifecycle: understand the layers a call actually passes through.
  3. Messages, Configuration, and Version Awareness: design a provider-neutral request contract.
  4. Structured Output and Streaming Responses: parse complete and incremental results correctly.
  5. Timeouts, Errors, Rate Limits, and Retries: apply controlled retries only to recoverable errors.
  6. Usage, Observability, and Provider Adapters: make requests traceable, comparable, and replaceable.
  7. Reliable Client Project and Self-Tests: run unit tests with a mock transport.
  8. Provider Contract Tests: parse the current streaming tool-call contracts of three providers and construct correct continuations.
  9. Common OpenAI Responses API Patterns: move from a minimal request to multi-turn state, streaming, structured output, tools, retrieval, and image input.
  10. OpenAI Platform API Keys and Codex OAuth: Authentication, Routing, and Runtime: distinguish Platform, WIF, and Codex OAuth, and understand OpenClaw authentication, model routing, and runtime selection.

Hands-on projects

First complete the reliable client project: reliable_client.py defines strict request/response contracts, error classification, Retry-After, exponential backoff, jitter, dual attempt/deadline limits, and a canonical streaming state machine with event/text resource boundaries. Twenty-two offline tests validate success and failure paths.

Then complete the provider contract tests: a standard-library implementation separately consumes OpenAI/Gemini typed SSE projections and an Anthropic wire-SSE envelope projection, and releases calls only after a provider terminal state. Five constructors validate stateful/stateless continuation, caller-validated canonical history, caller controls, complete result sets, and prior/current storage boundaries. The constructors perform bounded JSON, identity, and required-field checks, but do not turn arbitrary caller history into a provider-authenticated session. Ninety-nine tests cover event drift, interleaving, truncation, errors, replay, official-source host/path attacks, Anthropic fallback-beta fail-closed behavior, and resource limits. The two layers total 121 tests, but still do not replace real SDK/API integration tests.

Mastery standard

  • Explain why an SDK’s default retry plus a second wrapping retry can multiply attempts.
  • Set boundaries for connection, first byte, whole request, and business deadline rather than waiting indefinitely.
  • Distinguish parseable JSON, schema compliance, semantic correctness, and an authorized action.
  • Continue handling error events and incomplete termination after streaming HTTP has returned a success status.
  • Isolate provider differences behind a stable application interface without pretending that all parameter semantics are identical.
  • Locate the configuration and failure reason for a request without recording raw sensitive content.
  • Run the 22 reliable-client tests and 99 provider-contract tests, and demonstrate that unknown exceptions, permanent errors, in-stream failures, error association, resource-limit violations, and missing terminal events are never misclassified as success.
  • Explain why SDK automatic retries, provider call IDs, business idempotency keys, and exactly-once are different mechanisms.

Relationship to other knowledge bases

Primary references

Backlinks