Applications and Integration — study note
This note covers Domain 2 of the Claude Certified Developer – Foundations exam, the largest domain. It has six skills, all covered here:
- understanding requirements;
- the systems life cycle;
- Claude API mechanics;
- software engineering foundations;
- Claude application design;
- configuration management.
It summarizes what each topic teaches and the Anthropic pages behind it. On purpose, it teaches mechanisms rather than numbers. Model names, prices, size limits, retirement dates and rate limits change often, so look them up on the relevant pages when you need them. Where it gives general engineering advice beyond those pages, it says so.
From requirement to success criteria
Building a successful application starts with clearly defining success criteria and then designing evaluations to measure performance against them. Anthropic calls this cycle central to prompt engineering. Its prompt engineering overview assumes you already have criteria and a way to test against them; if not, establish those first.
| Requirement sounds like | Criterion class |
|---|
| Same answer to a rephrased question | Consistency |
| Builds on what was said earlier | Context utilization |
| Right language for the audience | Tone and style |
| On the question, easy to follow | Relevance and coherence |
- Define the words. A criterion such as “90% of errors cause inconvenience, not egregious error” needs definitions of inconvenience and egregious before anyone can grade against it.
- Qualitative is allowed. Qualitative measures can be valuable when applied consistently alongside quantitative ones.
- Stuck? Brainstorm success criteria with Claude, with the criteria guide as guidance.
Evaluations that fit the criterion
| Criterion | Method | Test cases |
|---|
| Summary quality | ROUGE-L | Reference summaries |
| Consistency | Cosine similarity | Groups of paraphrases |
| Context use | LLM ordinal scale | Multi-turn chats |
| Subjective tone | LLM Likert scale | Target-tone inquiries |
- Mirror the task. Evaluations should mirror the real task distribution, edge cases included: irrelevant or nonexistent input, overly long input and, for chat, poor, harmful or irrelevant user input.
- Automate grading where you can, and get Claude to help generate more cases from a baseline set.
Production guides
Anthropic publishes production guides for common use cases: ticket routing, customer support agent, content moderation, legal summarization and a commerce agent blueprint. House advice: treat a guide as a starting set of requirements and adapt it to yours.
The model life cycle
| Status | Meaning |
|---|
| Active | Fully supported and recommended |
| Legacy | No more updates; may be deprecated |
| Deprecated | Works, not recommended; replacement and retirement date assigned |
| Retired | No longer available; requests fail |
- Plan the move. Migrate all usage before the retirement date, and test the replacement well before it. Deprecated models are likely to be less reliable than active ones.
- Find the usage. Export usage from the Console's Usage page for a CSV broken down by API key and model.
- Parameters deprecate too. How the API treats a deprecated parameter depends on the model. Some SDKs remove parameters outright; most keep them in their types, so a clean type-check proves little.
- Partner platforms set their own lifecycle dates, which can differ from the Claude API schedule.
API versions
Every request sends an anthropic-version header; the client SDKs send it for you. Anthropic recommends the latest version.
| Preserved within a version | May still change |
|---|
| Existing input parameters | New optional inputs |
| Existing output parameters | New output values |
| Error-type conditions |
| New enum variants |
If you use the API as documented, Anthropic generally will not break your usage. Write code that tolerates additions.
Migrating to a newer model
Each model ID is a pinned version; updates ship under new IDs, and the guarantee covers IDs, not convenience aliases. Read the migration guide for the model you move to. Recurring patterns:
| Old habit | On newer models |
|---|
| Prefill to continue a reply | Continuation in a user message |
| Prefill to skip a preamble | System-prompt instruction |
| Prefilled persona reminders | Reminders in the user turn |
| No thinking by default | Disable thinking explicitly |
| Hand-parsed tool JSON | A standard JSON parser |
Also review prompts, since newer models are more concise and direct, and review max_tokens for workloads that ran without thinking.
Messages, data and streams
- Stateless. Send the full conversation every time. Earlier assistant turns may be synthetic. Standing instructions go in the top-level
system field.
- Data access. The Models API lists models; the Files API stores a file once for reuse; newer lists page with
page and limit, while batch and model lists use after_id and before_id. SDK auto-pagination only goes forward. A request over the size limit returns 413.
- Streams.
message_start carries an empty content; replies arrive in content-block events, reasoning in thinking_delta events, top-level changes in message_delta events.
- Tool arguments arrive one complete key and value at a time; fine-grained streaming can be enabled per tool.
- Recovery. Capture what arrived, send a continuation (a user message on newer models), resume. Prefer the SDK's accumulation.
Images and thinking
| Image source | Use it when |
|---|
| base64 | Any platform; one-off images |
| URL | Image hosted online |
file_id | Reused images, long sessions |
- On partner-operated platforms, only base64 sources are currently available.
- Label several images, put them before the text, and send anything not in the pixels (such as metadata) as text.
- Claude cannot reliably detect AI-generated images; counts are approximate; animations use the first frame.
- Heavy compression can hurt accuracy; inspect the images you actually send.
- Moving from a manual thinking budget to adaptive thinking is a behavioural change: adaptive thinking decides whether to think. The response usage reports thinking tokens; when streaming, on the final
message_delta only.
Realtime, batch and cloud platforms
- Batch what no one is waiting on. Requests run independently; streaming and fast mode are refused; params are validated at the end, so dry-run one request first; canceled batches keep partial results.
- Google Cloud puts the model in the URL and the version in the body. Global endpoints suit flexible residency, multi-region a broad geography, regional a single region or provisioned throughput.
- Amazon Bedrock runs inside the AWS security boundary; a service role is the recommended long-lived authentication.
Requests, SDKs and clients
| Header | Needed |
|---|
| API version | Always |
| Content type | Always |
| Workspace ID | Some keys |
- Authentication.
Authorization: Bearer carries an API key or a short-lived token; x-api-key is a legacy fallback that still works. A federation token picks its workspace at exchange, so it never takes the workspace header. An SDK sends authentication, version and content type for you.
- SDK caveats. The
extra_ request options override documented parameters of the same name, so use them only with trusted input. A field returned as null and a field never returned both read as None; model_fields_set tells them apart.
- Clients. Use the async client for concurrent services, and the
aiohttp backend for better async performance. Timeouts raise APITimeoutError and are retried twice by default. Override retries or timeouts for one call with with_options. Close clients you create; pass custom HTTP clients as DefaultHttpxClient.
- Shell scripts have an official tool: the
ant CLI.
Rate limits and errors
| Usage field | Counts? |
|---|
| input_tokens | Yes |
| Cache writes | Yes |
| Cache reads | Not usually |
- Token bucket. Capacity refills continuously, not at fixed intervals, and short bursts can exceed a limit. After a rate-limit 429, wait as long as
retry-after says.
- Output limits count tokens as they are generated;
max_tokens does not count against them.
- Headers show the limit, what remains and when it resets; the tokens headers show the most restrictive limit in effect, such as a workspace's.
- Workspaces can have lower limits, except the default workspace, and organization limits always apply. Limits are per model, and are ceilings, not minimums.
- Errors. Retry a 500 with backoff, then contact support with the request ID. A 504 suggests streaming. Error
type values can grow, and a stream can fail after a 200.
Claude Code in the delivery pipeline
- Refactor in small, testable increments that keep behaviour; tests follow your existing patterns; review each pull request and ask Claude for risks.
claude --from-pr finds sessions linked to a pull request.
- GitHub Action credentials. Share a Console API key, not a personal OAuth token; better, use workload identity federation with
id-token: write. Deleting a secret leaves its key valid; delete the key in the Console too.
- Scope each run. A plain-text prompt has no shell or GitHub access until you grant tools. Keep the
claude_args line that starts the inline-comment server. Cap turns, set workflow timeouts and limit concurrency. The official GitHub App's permissions are all-or-nothing; a custom app can be narrower.
Instructions that reach Claude
- Role and scope. A one-sentence role in the system prompt focuses behaviour; ask explicitly for fuller work; state identity and exact model strings when they matter; give design guidance for frontends.
- Tools. Independent calls run in parallel; keep dependent calls sequential and forbid guessed parameters; ask for sequential steps if parallel work strains a system.
- Safety. Consider reversibility: act on local, reversible steps, ask before hard-to-reverse or shared ones, and never take a destructive shortcut such as skipping a safety check.
- Claude Code. Its system prompt isn't published; standing instructions go in CLAUDE.md or
--append-system-prompt. The agentic loop is the same on every surface, so one set of instructions serves them all.
Output schemas
| Schema feature | Supported? |
|---|
| Local $ref | Yes |
| External $ref | No |
| Recursion | No |
- JSON outputs arrive in the text content block. Unsupported features return a 400:
allOf with $ref, enums of objects, lookaround and backreference patterns, array bounds beyond minItems of 0 or 1.
- They combine with batches and token counting, not with assistant prefilling.
Sessions
| Need | Use |
|---|
| One-process chat | SDK client |
| After a restart | Continue |
| Many users | Resume by ID |
- Read the session ID from the result message, present on success or error; a process failure yields none. Resume after a turn-limit error with a higher limit.
- A fork copies history, not files: its edits land in the shared directory.
persistSession: false keeps a TypeScript session in memory. Permission prompts inside one query() call are handled in the loop.
Plugins
- Use a plugin to package several skills, agents, hooks or servers; a single skill works on its own. A marketplace is a catalog; plugins load at startup or on reload.
- Scopes. User: you, everywhere. Project: the whole repository through committed settings, though each person installs it. Local: you, one repository. Cloud sessions skip local plugins.
- Enabled plugins cost context every turn; disable unused ones. Any plugin runs with your privileges; official names count only from Anthropic's repositories. Managed settings can allowlist marketplaces and force-install plugins.
Instruction files and settings
- AGENTS.md. Read alone when there is no CLAUDE.md; with both, only CLAUDE.md is read unless it imports AGENTS.md.
- CLAUDE.md hygiene. Files are concatenated, so conflicts may resolve either way. HTML comments are stripped. A local file lives in one worktree; share personal notes by importing from your home directory. Exclusions skip other teams' files, never managed ones.
- Settings. Managed settings win, then
--settings for one session, then the local file, then the shared project file, then user settings. Files are strict JSON; a bad entry is skipped; most edits apply live, some keys only at start.
Pinning models and plugin versions
- Model IDs are pinned per platform: Bedrock has its own format, Google Cloud matches the API, and each ID has its own retirement schedule. Pin a repository's model in shared settings; the startup header names the file that set it. Switching models mid-session re-reads the conversation uncached.
- Plugin dependencies track the latest release unless you declare a tested semantic-version range. Ranges resolve against git tags, so maintainers must tag releases. Cross-marketplace dependencies need the root marketplace's allowlist, and conflicting ranges fail the install.
Sources
