# Claude Developer Platform & your first API call

> Move from ‘ask Claude’ to ‘Claude is a component in software you own’.

Canonical: https://www.brainyxai.co.za/education/claude/api-and-platform
Markdown: https://www.brainyxai.co.za/md/education/claude/api-and-platform.md
Course: Claude Operator Track
Lesson: 6 of 9
Minutes: 16
Author: Brainyx AI

## What you will be able to do

- Describe the Messages API request shape at a high level
- Explain why secrets belong on a server, not in the browser
- Pick a starting model tier for cost vs quality experiments

## From chat to platform

When Claude is inside your product — support draft assist, internal tools, agents — you use the **Anthropic API** (Messages) via the Developer Platform / Console.

Mental model of a request:

1. You authenticate with an **API key** (server-side)  
2. You send **messages** (system + user/assistant turns)  
3. You choose a **model**  
4. Claude returns a response (text and/or tool calls)  
5. Your app decides what to show, store, or execute  

Never ship API keys in frontend bundles. Brainyx AI (and any serious build) keeps keys in server env / secret stores.

## Model tiers (operator view)

Anthropic offers multiple model tiers trading off speed, cost, and capability. Exact names change — check the [models docs](https://docs.anthropic.com). Operator practice:

- **Prototype** on a mid tier you can afford to spam  
- **Eval** with a fixed set of golden prompts before “upgrading everything”  
- **Route** easy tasks to cheaper/faster models; hard reasoning to stronger ones  

## Minimal eval before you scale

Ten real prompts from your domain beat a hundred toy demos. Score: correctness, tone, refusal quality, latency, cost.

## Official references

- [API getting started](https://docs.anthropic.com/en/api/getting-started)  
- Academy catalog (Platform / API courses): [anthropic.skilljar.com](https://anthropic.skilljar.com/) — take them on Anthropic’s platform  

Brainyx AI builds owned backends around these APIs — this lesson is literacy so you can scope an engagement intelligently.

## API orientation lab

1. Create a Console account / workspace if you don’t have one (or use your team’s).
2. Generate a key into a local .env that is gitignored — do not paste it into this site or a public gist.
3. Run the smallest Messages hello-world from Anthropic’s docs in a server-side script; print only the text reply.

## Checkpoints

- Keys stay server-side
- I have a tiny eval list before model shopping

## The architecture decision hiding in your first API call

The first real decision is not which model — it is where the key lives. Any design where the browser holds the API key is broken, because anyone can read it and spend your budget. The correct shape is boring and non-negotiable: browser calls your server, your server holds the key and calls the model, your server returns the result.

That server layer is also where everything else you will need has to live: request logging, per-user rate limits, spend ceilings, prompt versioning, and the ability to swap providers without touching the front end. Teams that skip it end up rebuilding it under pressure after a bill or an incident.

## Model tiers as an economic choice

Treat model selection as routing, not as picking a favourite. Cheap fast models handle classification, extraction, routing, and short summaries — often the majority of production calls. Capable models handle genuine reasoning, long synthesis, and anything customer-visible where quality is the product.

Build the routing seam early even if you start with one model everywhere. Retrofitting a provider abstraction into code that calls one SDK directly across forty files is a bad afternoon.

## Cost modelling before you commit

Estimate in the currency you actually budget in. Take your expected volume, multiply by average tokens in and out, and convert to Rand at a realistic exchange rate. Then double it, because early implementations retry, over-fetch context, and log more than planned.

The number that matters is cost per completed business task — per resolved ticket, per processed document — not cost per thousand tokens. A more expensive model that halves the escalation rate is usually cheaper.

## Latency and operating from South Africa

Round-trip latency from South African infrastructure to overseas model endpoints is real and shows up in interactive experiences. Design around it: stream responses so users see progress, do retrieval and preprocessing close to your data, and avoid chaining several sequential model calls where one well-designed call would do.

For anything user-facing, measure perceived latency with real users on real connections, not on your fibre line at 2am.

## Mini-FAQ

**Q: What is the minimum production checklist?**
A: Server-side keys, structured logging of requests and outcomes, per-user rate limits, a spend ceiling with an alert, and a documented rollback for prompt changes.

**Q: Should I stream responses?**
A: For anything a human waits on, yes. It changes perceived speed far more than model choice does.

**Q: How do I stop a runaway bill?**
A: Hard caps at the application layer plus provider-side budget alerts. Never rely on the provider dashboard alone.

## Next lesson

Continue to [agents, tools, and MCP](https://www.brainyxai.co.za/education/claude/agents-tools-mcp).

Official reference: https://docs.anthropic.com/en/api/getting-started

Course hub: https://www.brainyxai.co.za/education/claude · Previous: https://www.brainyxai.co.za/education/claude/claude-code-basics · Next: https://www.brainyxai.co.za/education/claude/agents-tools-mcp