Tool

Anthropic API

Usage-based API access to Claude models

Tool

Usage-based API access to Claude models

Newsletter

One email on Fridays, and nothing else.

  • Practical B2B tips

  • 4-min read on Fridays

  • For anyone in B2B growth

About Anthropic API

  • Free option
  • API
  • MCP

Ultimate guide

This guide gets you from "I have an API key" to running Claude inside your own products and internal workflows with confidence: structured outputs, tool use, prompt caching, and the cost discipline that keeps a high-volume account from surprising you. It is written for founders and operators who want to build on Claude directly rather than through a no-code wrapper, the people who treat the model as infrastructure and want to own how it behaves.

Getting set up

Start with an organisation, not a personal toy account. Create your Anthropic account, then think of the Console as the place where three things live: your API keys, your usage and billing, and your workbench for testing prompts. Keep those three mental boxes separate from day one, because conflating them is how teams end up with a single shared key powering production, staging, and someone's local experiment all at once.

The decision that matters most early is key hygiene. Issue a distinct key per environment and per service, never one master key pasted everywhere. A key is a credential, so it belongs in a secret store (your platform's environment variables, a vault, a secrets manager), never in a committed file and never in front-end code where a browser can read it. If you only do one thing from this section, make it this: the model talks to your server, your server holds the key, and the client never sees it.

Next, pick your default model deliberately. Anthropic ships a family that trades cost against capability, so choose the smallest model that reliably passes your task, then reach for a larger one only where the work genuinely needs it. Wire model choice as configuration, not a hard-coded string, so you can swap or upgrade without a code change. Set a spending limit in the Console before you ship anything, and turn on usage alerts so the first sign of a runaway loop is an email, not an invoice.

Finally, decide how you call it. The official SDKs (Python and TypeScript) handle retries, streaming, and typing for you, so prefer them over hand-rolled HTTP unless you have a reason. Get a single round-trip working end to end, key loaded from the environment, one message in, one response out, before you build anything on top.

How to actually use it

The core unit is the Messages call: you send a list of messages and an optional system prompt, and you get a structured response back. Work in this order.

First, write the system prompt as the model's standing brief, who it is, what it must and must not do, the format you expect. Keep it stable across calls so you can cache it later. Put the variable, per-request content in the user message, not the system prompt.

Second, get the output into a shape your code can trust. Asking for prose and then parsing it by hand is fragile. Instruct the model to return JSON matching a schema you define, or better, use tool use (also called function calling) to force a structured payload. Tool use is the workhorse: you describe a "tool" with a typed input, the model fills in the arguments, and you get clean fields instead of guessing where a value sits in a paragraph.

Third, turn on streaming for anything a human waits on. Streaming returns tokens as they generate, so a chat or a long generation feels instant rather than frozen. For background jobs where nobody is watching, skip it and take the full response in one piece.

Fourth, handle the unhappy paths properly: rate limits, transient errors, and the occasional malformed output. Wrap calls with retry-and-backoff (the SDKs help here), and validate structured output against your schema before you trust it.

Power moves

Prompt caching is the single biggest lever, and most people leave it off. When a large chunk of your input repeats across calls (a long system prompt, a knowledge base, a fixed set of instructions), mark it as cacheable so Anthropic stores it and you pay a fraction to reuse it on the next call. For high-volume products this changes your unit economics, not your latency by a little, your bill by a lot.

Use the Batch capability for work that is not time-sensitive. Classifying thousands of records, enriching a backlog, generating a library of variants: submit it as a batch and accept a slower turnaround in exchange for a meaningfully lower price per call. Reserve real-time calls for the moments a human is actually waiting.

For complex reasoning tasks, reach for extended thinking, where the model works through a problem before answering. It costs more, so apply it surgically to the hard cases (analysis, multi-step planning) rather than blanketing every request with it.

Two more that separate pros from beginners: stop-and-continue tool loops, where the model calls a tool, you run it, you feed the result back, and it continues, which is how you build agents that actually do things rather than just describe them. And aggressive evaluation: keep a small set of real inputs with known-good outputs, and re-run them whenever you change a prompt or model, so you catch a regression before your users do.

Where it fits your stack

The Anthropic API is the engine room, so it sits behind your own backend rather than next to your tools. The common shape: your application server (or a Supabase edge function, a serverless function, a worker) holds the key, calls Claude, and returns the result to your front end. Tool use is the bridge to the rest of your stack, you expose your database lookups, your CRM, your internal APIs as tools, and Claude orchestrates them.

For agentic and IDE work, the API also underpins the Claude developer tooling and the Agent SDK, so a workflow you prototype in an assistant can graduate into a production service on the same model. Wire usage data into wherever you already watch cost, and treat the API spend as a line item you monitor like any other infrastructure bill.

Pitfalls to avoid

The expensive mistakes are predictable. Leaking a key into client-side code or a public repo is the worst, rotate immediately if it happens and never ship a key to the browser. Defaulting to the largest model for everything burns money on tasks a smaller model handles fine. Skipping prompt caching when your inputs clearly repeat leaves a large saving on the table. Trusting free-text output instead of forcing structure means your parser breaks the first time the model phrases something differently. Running an unbounded agent loop with no maximum step count or budget guard is how a bug becomes a bill. And shipping a prompt change with no evaluation set means you are flying blind on quality. Each of these is avoidable with a habit, not a heroics: secrets in a vault, model as config, cache the repeats, force the schema, cap the loop, keep an eval set.

INTERVIEW EWOUD: Which Claude model do you default to for Solid Growth's products and internal agent work, and where do you deliberately step up or down the family?

INTERVIEW EWOUD: What is the one Anthropic API workflow you rely on most across your ventures, and how is it wired (edge function, batch job, agent loop)?

INTERVIEW EWOUD: What is your hard-won tip on controlling Anthropic API cost at the volume you run, prompt caching, batching, or something else you learned the expensive way?

Ideal for

Developers and technical teams building AI applications, agents, or automations on Claude models

Description

The Anthropic API (Claude Developer Platform) gives developers programmatic access to the Claude family of large language models for text, code, and vision tasks via a usage-based pricing model. It includes a developer console, SDKs, tool use, a native web search tool, citations, and Model Context Protocol (MCP) connector support. It is aimed at developers and teams building AI applications, agents, and integrations rather than end-users of a chat product.

Review

The Anthropic API is the direct, programmatic way to call Anthropic's Claude models from your own code. You send it a prompt (and optionally tools, documents, or a long conversation history) and it returns Claude's response, which means you can put Claude's reasoning and writing inside your own product, internal tooling, or automation rather than working through a chat window. It is the same family of models that powers Claude.ai, exposed as an HTTP API with official SDKs and a developer console for keys, usage, and billing.

Where it fits

This is for builders. If you are writing software that needs to read, reason over, summarise, classify, draft, or extract from text (or call your own functions through tool use), the Anthropic API is the layer you build on. It suits agentic workflows, internal automations, content pipelines, support deflection, document processing, and anything where you want Claude's judgement wired into a real system rather than copy-pasted by a human.

It is genuinely strong for teams that care about following instructions precisely and about safety, and for long-context work where you feed in large documents or whole codebases. It is also the natural backend if you are already living in Claude Code or building agents.

It is not for non-technical users who just want to chat: that is what Claude.ai is for. It is not a no-code tool, and it is not the cheapest option if your task is trivial and a smaller model elsewhere would do. If you have no engineer (or no agent doing the engineering), you will not get value from the raw API directly.

The honest take

The strengths are real: Claude is excellent at instruction-following, structured output, and long-context reasoning, the SDKs are clean, the docs are good, and tool use plus prompt caching make it practical to build serious agents on top. For a workload where output quality and reliability matter, it is one of the few APIs I trust to do what I asked rather than something adjacent.

The trade-offs are equally honest. You pay per token, so cost discipline (caching, picking the right model size, trimming context) is on you, and it adds up fast at scale. You are tied to one vendor's model line and its rate limits, so capacity planning matters. And like any LLM API, it can still be wrong or make things up, so you must build verification around it rather than trusting raw output. It is a powerful engine, not a finished product: the value comes from what you wrap around it.

INTERVIEW EWOUD: What is your personal verdict on the Anthropic API, and your star rating out of five?

INTERVIEW EWOUD: Is it in your own stack, and if so, what are you running on it and why?

INTERVIEW EWOUD: What is the one line you would tell a peer who is deciding whether to build on it?

Academy

Growth Academy

Start free

A free account opens the first course and keeps your progress.

  • A free course

  • Track your own skills

  • Every playbook you unlock