1. Start with the Messages endpoint and headers
The Anthropic Messages API turns a conversation into a structured request. You send instructions, conversation messages, and generation settings. The server returns an assistant message containing content blocks, plus metadata that tells your application what happened.
For direct Anthropic access, send a POST request to https://api.anthropic.com/v1/messages. The standard headers include x-api-key for authentication, anthropic-version for the API version, and Content-Type set to application/json. Keep credentials on your server or in environment variables, never in browser code or a committed example.
2. Build the smallest useful request body
A basic request needs three fields: model, max_tokens, and messages. The model field selects an available model identifier. The max_tokens field limits the generated output; it does not set the size of your input. The messages field contains the conversation you want the model to continue.
A minimal body looks like this: {"model":"YOUR_MODEL_ID","max_tokens":256,"messages":[{"role":"user","content":"Explain an API in one sentence."}]}. Replace YOUR_MODEL_ID with an identifier supported by your provider. Treat this example as a shape to copy, not a ready-to-run model selection.
3. Put application instructions in the system field
Use the top-level system field for application-wide instructions, such as tone, output format, and task boundaries. For example, add "system":"Explain technical concepts in plain English." alongside model, max_tokens, and messages.
Unlike some other chat formats, the native Anthropic Messages API does not put a system-role message inside the messages array. Conversation entries use user and assistant roles. Keeping these locations straight prevents a common integration mistake: copying a request from another API without translating its structure.
4. Read message content as a list of blocks
For a simple text input, content can be a string. The more general representation is an array of typed blocks: {"role":"user","content":[{"type":"text","text":"Explain an API in one sentence."}]}. Each block identifies what it contains.
This matters because messages are not always plain text. Supported requests can include images or documents, and tool interactions introduce their own block types. Build your parser around the type field rather than assuming every block has a text field. That small design choice makes later extensions much easier.
5. Send the history needed for the next turn
Standard Messages requests are stateless: the API does not automatically remember earlier requests. For a follow-up, include the relevant earlier user messages and assistant replies, then append the new user message. Preserve their order so the conversation remains understandable.
Store the assistant content blocks, not just a flattened text string, especially when tools are involved. Also avoid sending an unlimited transcript. Your application should retain the context needed for the task while respecting the selected model's context limits and your token budget.
6. Inspect the response before displaying text
The response includes fields such as id, role, model, content, stop_reason, and usage. Read text blocks from content for display, but inspect stop_reason before treating the turn as complete. An end_turn stop indicates a finished assistant turn; max_tokens means the output reached its configured limit.
Tool use adds another branch. You declare available tools in the request's tools field. The assistant can return a tool_use block containing a tool name, an identifier, and structured input. Your application validates and executes the operation, then sends a user message containing a matching tool_result block. The model requests the action; your code performs it.
7. Check provider routing before your first run
SwiftRelay is worth considering when you want pay-as-you-go, per-token access across multiple model families. Sign up for SwiftRelay to try the integration with the small gift credit available to new accounts. Its API host is https://api.fastapirelay.com.
Keep transport formats separate: an OpenAI-compatible SDK configuration is not the native Anthropic Messages schema. Check the provider's documented Anthropic-compatible endpoint, authentication requirements, and supported model identifiers before sending this request shape. Finish your first run by checking the HTTP status, content blocks, stop reason, and token usage before connecting the response to your application interface.