A1. Why This Series & Who It's For | Claude API Practitioner's Guide | DataMy

About this article This article is part of Building with Claude — A Practitioner's Guide to the Anthropic API, a study-notes-plus-commentary series based on Anthropic's official "Building with the Claude API" course (hosted on Coursera) and the public Anthropic API documentation at docs.anthropic.com.

Original course and documentation material is © Anthropic. Direct quotes are cited inline. Commentary, code adaptations, and examples are © DataMy. This series is independent and not affiliated with or endorsed by Anthropic.

The gap this series is trying to close

Most developers I meet are already using the Claude API. They just aren't using very much of it.

A typical pattern looks like this: someone wired client.messages.create(...) into a Python script or an n8n node, got a useful answer, and stopped there. Six months later, the same script is still in production. The model has been upgraded three times. Prompt caching has launched. Extended thinking has launched. MCP has launched. None of it is in the codebase, because the team never carved out time to read the docs end-to-end.

This series is for that team.

It is a re-read of Anthropic's "Building with the Claude API" course — the one currently published on Coursera — written from the perspective of someone who builds data and AI systems for a living. The goal is not to substitute for the course. The goal is to give a reader who already understands the basics enough of a map that they can decide which features actually matter for the thing they are building, and skip the rest with a clear conscience.

If you have never made an API call before, the official course is still the right starting point. If you have made dozens of API calls but have never touched tool use, caching, multimodal inputs, RAG, or MCP — this series is written for you.

Who this is for

You'll get the most out of this series if you can say yes to most of the following:

You can write basic Python and have run an Anthropic API call at least once.
You use Claude inside a tool, a notebook, a workflow engine, or a small internal app — but it's still essentially a "send prompt, get string" pattern.
You've read pieces of the Anthropic docs but never sat down and worked through them in order.
You want a clearer mental model of what the API can do, not just what the chatbot can do.
You're considering building agentic features, retrieval, or MCP integrations and want to know whether they're worth the effort.

You'll get less out of it if:

You've already shipped production tool-use loops, custom MCP servers, and contextual-retrieval pipelines. This series will feel slow.
You are looking for a deep theoretical treatment of transformers, embeddings, or reranking architectures. This series treats those as means to an end.
You want a vendor-neutral comparison across OpenAI, Gemini, Anthropic. This series is Claude-only.

What you'll be able to do at the end

By the time you finish all eleven articles, you should be comfortable:

Making a robust API call. Auth, model selection, streaming, retries, error handling, cost awareness.
Shaping behavior with prompts. System prompts, output discipline, structured output via prefill and stop sequences.
Feeding the model more than text. Images, PDFs, and long-context inputs — including knowing when not to.
Making the model think harder, cheaper. Extended thinking and prompt caching as two sides of the same coin: "augmenting the model's reasoning without paying for it twice."
Building a RAG pipeline that actually retrieves the right thing. Chunking, embeddings, hybrid search, reranking, contextual retrieval — and the judgment to know which layer you need.
Using tools. Both Anthropic's built-in tools (code execution, web search, text editor) and your own custom tool schemas with function calling.
Speaking MCP. Using existing MCP servers as a client, and building your own MCP server that wraps the custom tools from earlier in the series.

That is the entire surface area of the modern Claude API, treated as one coherent design space rather than twelve unrelated features.

What this series is not

A few honest disclaimers, because expectation-management is half the value of a practitioner guide.

It is not a substitute for the Anthropic docs. The docs are authoritative; the docs are updated faster than any blog series can be. When this series and the docs disagree, the docs are right.
It is not a substitute for the Coursera course. If you learn better from video, take the course. This series quotes from it and builds on it — it does not replace it.
It is not a "look how clever I am" tour. Every example is chosen because it's the kind of thing a working data or analytics engineer would actually build: a metrics copilot, a job-status assistant, a runbook-grounded RAG bot. If an example doesn't pay for itself in real-world usefulness, it isn't in here.
It is not exhaustive. Batch API, files API, message batches, fine-tuning-adjacent workflows — out of scope. The four parts below are the spine; the rest is reachable from the docs once the spine is in place.

The four-part arc

Part 1 — Foundations & Setup
  A1. Why this series                                  ← you are here
  A2. Setup and your first robust API call

Part 2 — Prompt engineering & advanced prompting
  B1. System prompts, roles, and output control
  B2. Multimodal inputs: images and PDFs
  B3. Augmenting model reasoning: extended thinking + prompt caching
  B4. RAG essentials: chunking, embeddings, hybrid retrieval
  B5. RAG advanced: reranking and contextual retrieval

Part 3 — Tools
  C1. Built-in tools
  C2. Custom tools / function calling

Part 4 — MCP
  D1. MCP concepts and using an MCP server as a client
  D2. Building your own MCP server

The arc is deliberate: make a real call → control what comes out → give the model eyes, memory, and reasoning → let it act through tools → standardize tool access via MCP. Each part assumes the previous one but nothing further. A reader who only cares about tools can jump from A2 directly to Part 3 without touching RAG.

How to read this series

Three reading modes, in increasing order of effort:

Map mode. Read A1, A2, and the opening section of each subsequent article. You'll come out with a working mental model of the API surface and know which features deserve a deeper look.
Linear mode. Read all eleven in order. Roughly a 2.5-hour read end-to-end.
Lab mode. Read linearly, but actually run the code as you go. Plan on a weekend. This is the mode that produces engineers who can ship.

About the source material

The series is built on three sources, in this order of authority:

Anthropic's official API documentation (docs.anthropic.com) — the source of truth for behavior, pricing, and limits.
Anthropic's "Building with the Claude API" Coursera course — the source of the curriculum spine. Direct quotes from the course are cited inline, and the structure of this series mirrors the course's logical progression while reorganizing it for a working-developer audience.
My own lab notebooks from working through the course in May–June 2026, plus production lessons from the data and AI projects I've built for enterprise clients in APAC.

Where Anthropic's material says something better than I could paraphrase, I quote it directly and attribute it. Where the docs are silent or where my production experience disagrees with the course's default recommendation, I'll say so and explain why.

About DataMy

This series is published by DataMy, a Singapore-based data & AI consulting practice working across APAC. DataMy helps enterprises modernize their data platforms, stand up analytics and BI capabilities, and put AI into production — both directly and as a delivery partner to Keyrus APAC. Day-to-day, that means we sit between vendor product teams (Tableau, Salesforce, Huawei, Databricks, Dataiku, Alation, Denodo, Securiti, Qlik, and others) and enterprise data teams in banking, manufacturing, retail, and the public sector.

This series exists because the same conversation keeps happening in our client engagements: a team is already using the Claude API for one narrow task and wants to understand what else the API can do for them — without committing two weeks to read the docs. We're publishing our own working notes so that conversation can start from a shared baseline.

The grounded examples used throughout the series — SaaS metrics tables, pipeline job logs, warehouse usage logs, runbooks, QBR reports — are the kinds of artifacts DataMy works with every week on real engagements. They are deliberately not generic.

Conventions used throughout the series

To save explaining the same thing eleven times:

Code blocks are Python 3.11+ unless otherwise marked, and assume anthropic>=0.40 and a working ANTHROPIC_API_KEY environment variable.
Direct quotes from Anthropic material are shown as a blockquote with an attribution line directly below, in italics.
Practitioner Notes sections appear at the end of most articles. That's where the "what would I actually do" judgment lives — the part you can't get from the docs.
"Beyond the docs" callouts mark places where I'm extending or pushing back on the official material, not just relaying it.

Practitioner Notes

A few things I wish someone had told me before I sat down with the API for real:

The biggest wins are not the flashiest features. Prompt caching and a disciplined system prompt will improve a real production app more than extended thinking will, nine times out of ten. Read in order; don't skip Part 2 to get to MCP.
Build the smallest thing first. A custom tool you wrote in an afternoon will teach you more about agentic behavior than reading three articles about MCP. Part 3 before Part 4 is the right order for a reason.
Cost and latency are features. Most beginner code ignores both. Half of moving from "moderate user" to "practitioner" is just learning to instrument them.

Next: A2 — Environment Setup & Your First Robust API Call

Series index: Building with the Claude API — A Practitioner's Guide