My first real GTM automation was a human cron job. Every Monday, someone on the team pasted the same prompt into the Claude app, fed it that week's inbound, copied the scored list into a sheet, and moved on. It worked, and it was also absurd: a person being the trigger for something software should trigger. The whole thing existed because we had not crossed the one line that changes everything, from a person using Claude to software using Claude.
That line is the API. It is how Claude stops being something you talk to and becomes something your systems call. This guide gets you from zero to a working request and, more importantly, clear on when the API is the right tool and when the app or Claude Code still wins.
What the API actually is, and when you need it
The Claude API is an endpoint your code sends a request to and gets Claude's response back. That is the entire idea. Where the app is you having a conversation and Claude Code is you handing an agent a job, the API is your software making the call, no human in the moment. It is the surface you reach for when the thing that should decide is a program, not a person.
So the test for whether you need the API is simple: is a person going to be sitting there each time. If yes, the app or Claude Code is almost always simpler and better. If no, if this should run on a schedule, at volume, or inside another system, that is the API's job, and nothing else does it as cleanly.
One more framing that saves confusion: the API is a building block, not an application. It gives you the model behind an endpoint, and the scheduling, the retries, the storage, the interface are yours to build around it. That is not a burden, it is the point, because it means Claude drops into whatever system you already run instead of forcing you into a new one.
The one shape: the Messages API
Almost everything you will do runs through one endpoint, the Messages API, and it has one shape: you send a list of messages, Claude sends one back. Tools, streaming, caching, vision, all of it layers on top of this same request-and-response. Learn this shape and the rest is additions to it, not new things to learn.
That simplicity is worth holding onto, because it means your first call and your hundredth production call are the same motion. You are never fighting the API's structure, you are just adding capabilities to a request you already understand.
Get a key, and keep it safe
You authenticate with an API key, created in the Anthropic console. The key is a credential, which means it is also a way for someone to spend your money if it leaks. Treat it the way you would treat a password to a system that bills you: it goes in an environment variable or a secrets manager, never hard-coded, never committed, and absolutely never in front-end code where a browser could read it.
This is the single most common expensive mistake with the API, so it is worth being blunt: a key in client-side JavaScript is a key the whole internet can use. Keep every call server-side, and keep the key in the environment.
TipIf a key ever lands in a commit or a browser bundle, rotate it immediately in the console. A leaked key is spent money waiting to happen, and rotating is the fix, not deleting the file.
Your first call
The SDK does the heavy lifting. You install it, point it at your key, and make one Messages call. The how-to below has the exact commands, but the shape is: import the client, call messages.create with a model and a message, and read the text off the response. It is a dozen lines, and most of them are boilerplate you write once.
The thing to notice is how little there is. There is no session to manage, no server to run, no ceremony. One function call, one response. That is deliberate, and it is why wiring Claude into an existing system is usually an afternoon, not a project.
The parts of a request
Four pieces make up a request, and each earns its place. The model decides the engine, and you pick it per task the way you would in the app: a cheap fast one for volume, a stronger one for hard reasoning. The system prompt sets standing behavior, your voice rules, the role Claude is playing. The messages are the actual conversation. And max_tokens caps how long the response can run.
The system prompt is where operators get the most return. It is the same idea as a CLAUDE.md or a Project's instructions: say once who Claude is being and what the rules are, and every message in that request inherits it. Put your voice and your constraints there, not in every user message.
- model: the engine, chosen per task. Check the models page for the current identifier.
- system: standing behavior and rules, set once for the whole request.
- messages: the conversation, a list of user and assistant turns.
- max_tokens: the ceiling on the response length, which also caps its cost.
Reading the response, and the bill
The response gives you the content, Claude's reply, and a usage block with input and output token counts. Read the content and you have your answer. Read the usage and you have your cost, because tokens are how the API is priced. Logging usage from your very first call is the habit that keeps a bill from surprising you three months in.
This is a quiet advantage of the API over the app for anything at scale: cost is visible and per-call, so you can see exactly what a job costs and decide if it is worth it. You are never guessing at spend, you are reading it off every response.
TipLog the usage block on every call from day one. Cost visibility is free here, and the automation that scales quietly is the one you can also cost out precisely.
Where first calls go wrong
Beyond the leaked key, the early stumbles are predictable. No error handling, so a rate limit or a network blip crashes the whole job instead of retrying. A model chosen out of habit rather than fit, usually the most expensive one for a task that a cheaper model would nail. And forgetting that the API has no memory between calls: each request is fresh, so any context Claude needs, you send every time.
That last one trips up people coming from the app, where the conversation just persists. On the API, you are responsible for the conversation. If a call needs history, you include the prior messages. If it needs your positioning, you send it. Nothing carries over on its own.
- The key in client code or a commit. Keep it server-side, in the environment.
- No retries or error handling around the call, so one blip kills the job.
- Defaulting to the priciest model for work a cheaper one would do fine.
- Expecting memory between calls. Each request is fresh; you send the context.
From one call to a reliable job
A working call is not yet a reliable job, and the gap is worth closing before you schedule anything. Real usage hits rate limits and transient network errors, so wrap the call in a retry with backoff and do not let one blip kill a run over five hundred leads. Log every call's outcome and usage, so when something looks off next week you have a trail instead of a shrug.
The other half is idempotency: if a job re-runs, it should not double-write. Key your writes on something stable, the account id, the lead's email, so a retry updates rather than duplicates. None of this is exotic, it is the difference between a script that works on your laptop and a job you trust to run at three in the morning without you.
The GTM version: what to build first
The first thing to build is the human cron job you are already running by hand. The Monday lead-scoring paste. The nightly enrichment someone does with coffee. The follow-up drafts a rep generates one at a time. Each of those is a person being a trigger, and each becomes a scheduled API job that runs whether or not anyone remembers.
Start with one, the most tedious and most repeated, and wire it end to end: pull the input, call Claude, write the result somewhere useful. Once you have done it once, the pattern repeats for the next ten. What is the task your team does every week by hand that a program should have been doing all along?
How to set it up
Get a key and store it in the environment
Create a key in the Anthropic console, then put it in an environment variable so it never touches your code or a commit.
Make your first Messages call
A dozen lines gets you a working call. The SDK reads the key from the environment automatically:
TipCheck the models page for the current model identifier before you ship; model names move, and the API rejects an outdated one.
Read the reply and the usage
The response carries both the text and a usage block. Read the text for your answer, and log the usage so you can cost every call from the start.
Turn one hand-run task into a scheduled job
Take the most repetitive thing your team does in the app by hand, the weekly scoring, the nightly enrichment, and wrap this call in a script that pulls the input and writes the result. Then schedule it. The human cron job becomes an actual one.
Frequently asked questions
When should I use the API instead of the Claude app or Claude Code?
Use the API when software, not a person, makes the call: scheduled jobs, high volume, or Claude embedded inside another system. If a human is sitting there each time, the app or Claude Code is simpler.
How do I get an API key?
Create one in the Anthropic console. Store it in an environment variable or a secrets manager, keep every call server-side, and never put it in front-end code or a commit.
What is the Messages API?
The core endpoint: you send a list of messages plus a model and get one response back. Tools, streaming, caching, and vision all layer on this same request-and-response shape.
Does the API remember previous conversations?
No. Each request is independent. If a call needs prior turns or standing context like your positioning, you include them in the request every time.
How is the API priced?
By tokens, counted separately for input and output. Every response includes a usage block, so log it from your first call to keep cost visible and predictable.
Which model should I call?
Pick per task, the same way you would in the app: a cheaper, faster model for high-volume or simple work, a stronger one for hard reasoning. Check the models page for current identifiers.
What is the system prompt for?
Standing behavior for the whole request: the role Claude plays, your voice rules, your constraints. Set it once instead of repeating instructions in every user message.
What is the first thing a GTM team should build?
The task you already run by hand on a schedule, weekly lead scoring, nightly enrichment, follow-up drafts. Wrap the call in a script, schedule it, and the human trigger disappears.
Sources & further reading
Claude ships fast. This page was last reviewed Aug 23, 2026; verify time-sensitive details against the official docs above before relying on them.