hidekazu-konishi.com

Moving a Claude Integration to API Version 2026-10-21 on AWS - Requests That Now Return 400, the Authorization Header, and Amazon Bedrock

First Published: 2026-10-28
Last Updated: 2026-10-28

On October 21, 2026, Anthropic released a new API version, 2026-10-21, for the Claude API. On the same day, new major versions of the SDKs and the ant CLI were also released, which default to this version. This article details the changes required when migrating AWS-based Claude integrations to this new API version, outlining which requests now return a 400 error, which header carries the API key, and which paths remain on the older API version.

This article covers four paths: the Claude API behind AWS gateways and proxies, Amazon Bedrock (referred to as Bedrock) endpoints bedrock-runtime and bedrock-mantle, and Claude Platform on AWS. For each path and each setting, it records what users can write, what values can be retrieved, what happens when certain inputs are missing, what happens at the boundary, where this information is visible, and what the sources do not state. Where Anthropic's documentation, AWS's documentation, and the SDK source give different values for the same thing, each value is set out with its source.

This article does not provide a table mapping parameters across four providers, cover migration across model generations, cover the whole of IAM and CloudTrail for Bedrock's two endpoints, or address pricing. It does not say which API version or path is better. The information presented was verified as of October 27, 2026. The records in Section 9 come from requests sent for this article from a local machine and in the US East (N. Virginia) Region.

Related articles on this site:

• LLM API Parameter Compatibility Reference - Anthropic, OpenAI, Google Gemini, and Amazon Bedrock
• Anthropic Claude Model Migration Guide - Upgrading Prompts and Workloads Across Model Generations
• Amazon Bedrock Inference Endpoints and API Keys - What bedrock-runtime and bedrock-mantle Each Accept, Which IAM Action Each Call Checks, and What CloudTrail Records
• Anthropic Claude API Errors Reference - HTTP Status Codes, Error Types, Causes, and Official Solutions
• Running Claude Apps Gateway on AWS - What the Gateway Holds and Enforces, What Stays on Developer Machines, and Where the Worked Example Stops
• What a Translating LLM Gateway Drops - Thinking Blocks, Signatures, Cache Breakpoints, Tool Call IDs, and Citations on Each Route Between the Messages, Chat Completions, Responses, and Converse APIs
• Amazon API Gateway Decision Guide - REST, HTTP, and WebSocket APIs and Integration Patterns
• Receiving Claude API OpenTelemetry Traces on AWS - What the Destination Must Accept, What CloudWatch Accepts, and What Sits In Between
• What Counts as a Data Plane Action on AWS - IsDataPlane in the Service Reference, CloudTrail Data Events, and What an SCP or RCP Can Scope
• Changing the Identity Source in IAM Identity Center Is Not Symmetric - What Survives in Each Direction, and What the Revision Field Guards

Table of Contents

1. 1. Scope and Assumptions
2. 2. How to Read the Tables
3. 3. What the API Version Changes on the Claude API
4. 4. What the New SDKs Send
5. 5. Gateways and Proxies in Front of the Claude API
6. 6. Amazon Bedrock
7. 7. Claude Platform on AWS and the Admin API
8. 8. Retaining Requests for API Version 2023-06-01
9. 9. What This Configuration Recorded
10. 10. Failure Modes
11. 11. Frequently Asked Questions about API Version 2026-10-21 on AWS
12. 12. Summary
13. 13. References

1. Scope and Assumptions

This section will first define the intended audience, the scope of this article, the source materials consulted, and how to distinguish between different entities that may share the same name. To begin, here are the seven conclusions.

• Whether a 400 error is returned depends on two factors: the API version and the model. With the 2026-10-21 API version, requests that include temperature, top_p, or top_k will return a 400 error for any model, even when using default values. With the 2023-06-01 API version, models Claude 4.7 and later, as well as Claude Mythos Preview, will return a 400 error when using non-default values. Older models (Claude 4.6 and earlier) will still accept non-default values.
• In API version 2026-10-21, both placing a document block directly within an assistant message, and providing non-empty citations within a user message's text block, will also result in a 400 error. These three changes apply to the Messages API, token counting, and each request within a Message Batch created with the 2026-10-21 API version.
• Newer SDKs (such as Python SDK 2.0.0) default to using the 2026-10-21 API version and send the API key using the Authorization: Bearer header. The Claude API accepts a key in either header. Clients for Microsoft Foundry continue to use x-api-key, while clients for Bedrock Mantle continue to send a bearer token. A client holds only one credential, and what fails when two are passed varies by SDK.
• Proxies and gateways that read or set the X-Api-Key header need changes. The migration guide shows how to write a configuration that sends a gateway token and the key for the API behind it in one request. When using Amazon API Gateway, the API key is received in the X-API-Key header when the receive method is set to HEADER. What happens when these two statements are put together is a reading of the sources, not a statement in them, and Section 5.4 says so.
• Anthropic's documentation states that, within Bedrock, the 2026-10-21 API version is available only for Claude 4.7 and later models (Section 9.5 has the record of this configuration). To continue using older models, you can either keep the SDK version unchanged or continue sending the current API version. The location and value for specifying the API version are inconsistent across the documentation. While AWS documentation specifies bedrock-2023-05-31 in the body of the InvokeModel request and 2023-06-01 in the header, the source code for Python SDK 2.3.0 includes 2026-10-21 in both locations. The header that carries the Bedrock API key is named differently by path and by source, and on bedrock-mantle the sources disagree.
• Anthropic's Versions page lists Claude Platform on AWS as supporting the 2026-10-21 API version. However, both the Anthropic documentation and the AWS user guide provide request examples that use the 2023-06-01 API version. The SDK client for Claude Platform on AWS is currently in beta.
• In the sources this article searched, no statement was found that gives a retirement date for the older API version 2023-06-01. The migration guide does, however, outline the option of keeping requests using the 2023-06-01 API version.

1.1 Intended Audience

This article is intended for developers and platform engineers who are implementing solutions that utilize Claude on AWS. These solutions may involve various architectures, including those using API Gateway, Application Load Balancers, custom proxies, the InvokeModel and bedrock-mantle features within Bedrock, or the Claude Platform on AWS. In particular, it is written for readers who hold one of the following six assumptions:

• Upgrading to a new major version of the SDK will not break existing functionality.
• As long as the temperature parameter is sent with its default value, it will not result in a 400 error.
• For Claude 4.6 and earlier models, the temperature parameter will continue to be supported.
• API keys will continue to be transmitted via the x-api-key header.
• Even within Bedrock, sending a new API version will result in new behavior.
• Older API versions will stop working at some point.

Each of these six assumptions is either inconsistent with the existing documentation, is a point on which the sources disagree, or lacks supporting evidence in the documentation. Sections 3 through 8 show which statement in which source says what.

1.2 Scope

This article covers API version 2026-10-21, the SDKs and the ant CLI that send it by default, the four paths on AWS, and the gateways and proxies placed in front of them.

The following topics are not covered:

• The mapping of parameters for four different providers, as detailed in the existing LLM API Parameter Compatibility Reference.
• Migration across different model generations (prompts, thinking, and prefill), as described in the existing Anthropic Claude Model Migration Guide.
• The APIs received by Bedrock's two endpoints, IAM actions, and CloudTrail logs, as outlined in the existing Amazon Bedrock Inference Endpoints and API Keys. Which kind of CloudTrail event a Bedrock inference call becomes is covered in What Counts as a Data Plane Action on AWS.
• What a gateway that translates formats drops, as detailed in the existing What a Translating LLM Gateway Drops.
• Specific details regarding paths within Google Cloud and Microsoft Foundry. Microsoft Foundry is mentioned only regarding key headers (Sections 4.2 and 9.2).
• Pricing, SDK licensing, and comparisons of model performance or capabilities.

1.3 Materials Reviewed and Verification Date

The materials reviewed for this article fall into four categories. All were obtained on October 27, 2026.

• Anthropic Documentation: Migration Guide (Migrating to API version 2026-10-21), Versions page, Release Notes, API Overview, Error pages, Model deprecations, SDK Overview, Claude in Amazon Bedrock (Opus 4.7 and later), Claude on Amazon Bedrock (Opus 4.6 and earlier), Claude Platform on AWS, Claude in Microsoft Foundry, Batch processing and Using the Messages API (obtained on October 28, 2026).
• SDK Source Code and Changelogs: Source code for Python SDK versions 2.3.0 and 1.17.0, as well as CHANGELOG files for each SDK and the ant CLI.
• AWS Documentation: Amazon Bedrock User Guide (Anthropic Messages API page, Claude Requests and Responses page, two pages on API Keys, two pages on Model Lifecycle, Document History, and the Claude Opus 4.7 model card obtained on October 28, 2026), Claude Platform on AWS User Guide, API Gateway Developer Guide, Elastic Load Balancing Application Load Balancer page, AWS WAF Developer Guide, AWS WAF API Reference.
• AWS Announcements: What's New.

The SDK versions are dynamic. The first releases that send 2026-10-21 by default came out on October 21, 2026, as stated in the release notes: Python SDK 2.0.0, TypeScript SDK 1.0.0, C# SDK 13.0.0, Go SDK 2.0.0, Java SDK 3.0.0, PHP SDK 1.0.0, Ruby SDK 2.0.0, and ant CLI 2.0.0. As of 03:58 UTC on October 27, 2026, the latest versions listed in each CHANGELOG were: Python SDK 2.3.0 (October 23, 2026), TypeScript SDK 1.3.0, Go SDK 2.3.0, Java SDK 3.3.0, PHP SDK 1.3.0, Ruby SDK 2.3.0, ant CLI 2.3.0, and C# SDK 13.3.0. Later on the same day, Go SDK 2.4.0 (17:00 UTC) and ant CLI 2.4.0 (17:25 UTC) were released on GitHub. While the source code was reviewed only for the Python SDK, for the other SDKs this article follows the statements in the migration guide.

1.4 Words That Look Alike, But Mean Different Things

This article contains many names that are spelled similarly but have different meanings. The following table tells them apart.

Name	Where it is used	What it is
anthropic-version	HTTP header on the Claude API, Claude Platform on AWS, bedrock-mantle, and the bedrock-runtime /anthropic route	The API version, such as 2023-06-01 or 2026-10-21
anthropic_version	Request body field of InvokeModel on bedrock-runtime	The version value inside the body; the AWS pages give bedrock-2023-05-31
2023-06-01, 2026-10-21	API versions on the Versions page	2023-01-01 is the initial release on the same page
Python SDK 2.0.0	Version of a client SDK	Not an API version; each SDK major version sends one API version by default
Claude API key	Created in the Claude Console	Sent as Authorization: Bearer by the new SDKs, or in x-api-key
Amazon Bedrock API key	Created through Amazon Bedrock (short-term or long-term)	A bearer token for Bedrock, held in AWS_BEARER_TOKEN_BEDROCK in the AWS examples
Claude Platform on AWS API key	Created in the AWS Console for Claude Platform on AWS	Authorized through aws-external-anthropic:CallWithBearerToken
API Gateway API key	Created in Amazon API Gateway	Read from the X-API-Key header or returned by a Lambda authorizer
Authorization	HTTP header	Holds a Claude API key, an auth token, an Amazon Bedrock API key, a SigV4 signature (AWS4-HMAC-SHA256), or a Lambda authorizer token, depending on the hop

The capitalization of header names varies from document to document. The migration guide uses X-Api-Key, the API overview uses x-api-key, and the API Gateway documentation uses X-API-Key. This article will cite each document using its respective header name spelling. The Application Load Balancer and AWS WAF pages state that header name matching is case-insensitive (see Section 5.3).

2. How to Read the Tables

This section defines the columns in the tables from Sections 3 through 6, how the source of a default is written, and how the sources of values are told apart.

2.1 Columns

The contract tables in Sections 3 through 6, in addition to the Setting column, use the following seven column names. The Setting column will list the API version, request parameters, headers, body fields, and SDK settings.

Column	What the cell holds
You Set	What the user can write, and where (a header, a request body field, an SDK option, or a gateway setting)
Allowed Values	The values the source lists, as of 2026-10-27
If You Set Nothing	What happens when the user writes nothing
Source of the Default	Which source states the value in If You Set Nothing
At the Boundary	What happens at an edge: the other API version, a model on the other side of Claude 4.7, a default value, two credentials, or a header that a gateway reads
Where It Shows	Where the result becomes visible: a 400 invalid_request_error, an SDK exception, a header in a log, or a missing field
No Statement Found	What the sources in Section 1.3 do not state

The contract tables come in pairs for each group of settings. The first table (What You Write) includes the columns Setting, You Set, Allowed Values, If You Set Nothing, and Source of the Default. The second table (What Happens) includes the columns Setting, At the Boundary, Where It Shows, and No Statement Found. The order of the rows is the same in both tables.

Table 3-1 in Section 3 has the following structure: Column 1 is Setting, Column 2 is 2023-06-01, and Column 3 is 2026-10-21. Table 6-1 in Section 6 has Setting in Column 1, and lists three Bedrock paths across Columns 2 through 4.

2.2 How the Source of a Default Is Written

The Source of the Default column holds one of the following labels:

Label	What it means
Migration guide	Migrating to API version 2026-10-21 (Anthropic)
Versions page	Versions (Anthropic)
SDK overview	SDKs, CLI, and libraries (Anthropic)
Bedrock page (Anthropic)	Claude in Amazon Bedrock (Opus 4.7 and later) (Anthropic)
Python SDK source (2.3.0)	The anthropic package source at version 2.3.0
Bedrock Messages API page (AWS)	Inference using Anthropic Messages API, Amazon Bedrock User Guide
API Gateway API key source page	Choose an API key source in API Gateway, API Gateway Developer Guide
No statement found	No source in Section 1.3 states the default

2.3 No Statement Found, Not Listed, the Sources Disagree, and Differs by API Version

This article writes each of four states with its own term:

• No Statement Found: Despite searching for information in Section 1.3, no text describing the matter was found. This corresponds to the No Statement Found column and the phrase no statement was found in the main text. This state does not mean that the matter does not exist or cannot be done.
• Not Listed: The item is not present in the list or table. In the main text, this is described as the documentation does not list. This also does not mean that the item is unusable.
• The Sources Disagree: Two different sources provide conflicting information regarding the same matter. The main text describes this as the sources disagree. This article does not presume that either source is incorrect. It will list the sources and dates, distinguishing between specification documents (guides, reference materials, source code) and announcement documents (release notes, What's New).
• Differs by API Version: The same matter is described differently in two different API versions (2023-06-01 and 2026-10-21). The main text describes this as differs by API version. This is not considered a discrepancy.

If the documentation provides examples of requests using an older API version, this article will not refer to it as a discrepancy. The API version used in the example will be stated as is.

2.4 Values the Documentation States, Values the SDK Source Sends, and Values Recorded in This Configuration

This article categorizes the origin of values into three categories:

• Values from Documentation: Values found in the text, tables, and examples in Anthropic and AWS documentation. In the text, this will be referred to as the documentation states.
• Values Sent by the SDK: Values that can be determined by examining the Python SDK source code. Each value carries its version and the date it was checked, and the text writes it as the Python SDK source (version 2.3.0, checked on October 27, 2026) sends. These values may change in later versions of the SDK.
• Values Recorded in This Configuration: Values recorded from the requests sent specifically for this article, as detailed in Section 9. In the text, this will be referred to as recorded in this configuration.

Sections 3 through 8 present only the values found in the documentation and the values sent by the SDK. The values in Section 9 are specific to the configuration used and the data recorded on that day, and do not represent values guaranteed by the documentation. Performance or comparative advantages cannot be determined based on the values presented in Section 9.

3. What the API Version Changes on the Claude API

This section lists the requests on the Messages API of the Claude API that API version 2026-10-21 makes return 400.

3.1 Three Kinds of Requests That Return 400 in API Version 2026-10-21

The Breaking changes section of the migration guide details three changes related to the Messages API.

First, concerning sampling parameters. The migration guide states, In 2026-10-21, a request that sends temperature, top_p, or top_k returns a 400 error, even at the parameter's default value. The Versions page states, The temperature, top_p, and top_k request parameters are removed. A request that sends any of them returns a 400 error on every model. This applies regardless of the value sent, and affects all models.

Second, regarding the document block within an assistant message. The migration guide states, In 2026-10-21, a request that places a document block directly in an assistant message returns a 400 error. It instructs users to send documents within user messages. Documents contained within other blocks will continue to be accepted. As an example, the migration guide names a web fetch tool result that Claude returned.

Third, concerning the citations field in a user message. The migration guide states, In 2026-10-21, a request that sends a text block with a non-empty citations array in a user message returns a 400 error. The Versions page clarifies that this also applies to the text block within a search_result block. The citations field within an assistant message's text block, as well as settings like "citations": {"enabled": true} for documents and search results, will continue to be accepted.

The migration guide states the scope of these three changes as These changes apply to requests to the Messages API (POST /v1/messages), to token counting, and to each request in a Message Batch created with 2026-10-21. The error code for 400 errors is invalid_request_error, as indicated on the error page.

3.2 Determined by API Version and Model

Whether a parameter results in a 400 error is not solely determined by the API version. The API parameters table on the Model deprecations page says, in the row for temperature, top_p, and top_k, Returns a 400 error. Earlier API versions return it when set to a non-default value on Claude 4.7 and later models and Claude Mythos Preview. Older API versions also return a 400 error when using non-default values with Claude 4.7 and later models, as well as Claude Mythos Preview. The same page also states: A new model can reject a deprecated parameter, and a new API version can remove it for every model.

Regarding Claude 4.6 and earlier models, the migration guide states: On models that accept other values, such as Claude Sonnet 4.6, a request that lowered temperature for more consistent output loses that effect. No other setting replaces it. If a request relies on a non-default value, either stop sending the parameter, or keep that request on 2023-06-01. Claude 4.6 and earlier models can use non-default values only when the request sends 2023-06-01.

The Using the Messages API page also states, The temperature, top_p, and top_k sampling parameters are not supported on Claude 4.7 and later models and Claude Mythos Preview, or on any model starting with API version 2026-10-21. Setting them to a non-default value returns a 400 error, and starting with 2026-10-21 any value does. The contrast, that any value returns 400 starting with 2026-10-21, can be read to mean that earlier API versions do not return 400 for the default value, but the page does not say so.

Table 3-1 below lists these two factors.

Setting	2023-06-01	2026-10-21
temperature, top_p, top_k omitted	Accepted; samples with the defaults	Accepted; samples with the defaults, the same as a 2023-06-01 request that leaves them out
Sent at the default value, Claude 4.6 and earlier	Accepted	400
Sent at the default value, Claude 4.7 and later and Claude Mythos Preview	No statement found (the Model deprecations and Using the Messages API pages name only non-default values)	400
Sent at a non-default value, Claude 4.6 and earlier	Accepted; the value takes effect	400
Sent at a non-default value, Claude 4.7 and later and Claude Mythos Preview	400	400
document block directly in an assistant message	No statement found	400
text block with non-empty citations in a user message	No statement found	400
Token counting with the changes above	No statement found	400 (the migration guide names token counting)

The No statement found cells in the 2023-06-01 column of Table 3-1 are of two kinds. The default-value row is there because the Model deprecations page and the Using the Messages API page name only non-default values and do not say that a default value avoids a 400. The document and citations rows are there because the migration guide and the Versions page write these two 400 errors only as changes in 2026-10-21. Section 9 records the result in this configuration for both.

3.3 The Defaults When the Parameters Are Omitted

The migration guide states Without these parameters, a request samples with their defaults, including a temperature of 1.0, the same as a 2023-06-01 request that leaves them out. Models that already accept only the defaults, such as Claude 4.7 and later models, sample as before.

If you omit these parameters, requests will sample using the default values in either API version.

Requests that previously used values other than the defaults will lose that effect when the parameters are omitted. As the migration guide states, No other setting replaces it. There are no alternative settings.

3.4 Contract Tables

The following two tables list what users input when using the Claude API, and the resulting outcomes.

What You Write

Setting	You Set	Allowed Values	If You Set Nothing	Source of the Default
anthropic-version	Request header (raw HTTP), or the SDK major version	2026-10-21, 2023-06-01, 2023-01-01	Required on raw HTTP; an SDK sends the version of its major version	Versions page, SDK overview
temperature, top_p, top_k	Request body	Removed in 2026-10-21	Samples with the defaults (temperature of 1.0)	Migration guide
document block	Content of a message	user message, or nested in another block, in 2026-10-21	Not applicable	Migration guide
citations on a text block	Content of a message	assistant message in 2026-10-21	Not applicable	Migration guide
Message Batch	Batch creation request	Created with 2023-06-01 or 2026-10-21	Not applicable	Migration guide

The following table lists events that occur at each boundary, in the same order as the rows above.

What Happens

Setting	At the Boundary	Where It Shows	No Statement Found
anthropic-version	Each SDK major version sends one API version	The version the request carries	A retirement date for 2023-06-01
temperature, top_p, top_k	2026-10-21: 400 on every model, even at the default. 2023-06-01: 400 only for non-default values on Claude 4.7 and later and Claude Mythos Preview	400 invalid_request_error	—
document block	2026-10-21: 400 when placed directly in an assistant message	400 invalid_request_error	Whether 2023-06-01 returns 400 for the same request
citations on a text block	2026-10-21: 400 in a user message, directly or inside a search_result block	400 invalid_request_error	Whether 2023-06-01 returns 400 for the same request
Message Batch	The changes apply to each request in a batch created with 2026-10-21; batch results use the API version of the request that created the batch (Batch processing page)	The result of each request in the batch	—

4. What the New SDKs Send

This section lists what the SDKs and the ant CLI that send 2026-10-21 by default put in a request.

4.1 The Default API Version

The SDK overview page states, Each major version of a client SDK sends one API version by default, and a new major version comes with each new API version. The migration guide explains, If you use an SDK, your requests use the API version that was current when your SDK's major version was released. When not using an SDK, the guide instructs users to include the anthropic-version header with the value 2026-10-21.

The migration guide, in the section on SDK changes, begins by stating, Earlier SDK and CLI versions sent anthropic-version: 2023-06-01 with every request. and continues by noting that newer versions send 2026-10-21. Regarding this scope, the migration guide writes including their Amazon Bedrock and Google Cloud clients. Bedrock clients also send 2026-10-21. Section 6 covers this.

Checking the source code of the Python SDK, the ANTHROPIC_API_VERSION constant in _constants.py is "2023-06-01" in version 1.17.0 and "2026-10-21" in version 2.3.0. The CHANGELOG lists the breaking changes in version 2.0.0 (October 21, 2026), including add support for new API version 2026-10-21.

4.2 API Key Headers

The migration guide states, The SDK and the CLI send your API key as Authorization: Bearer <key> instead of in the X-Api-Key header, so change any proxy or gateway that reads or sets X-Api-Key to use Authorization, or send the key in X-Api-Key yourself. The same section also requests that code within your programs that reads X-Api-Key (such as middleware, log filters, and test stubs) be modified, concluding with, The Claude API accepts a key in either header.

The table on the API overview page lists Authorization with a value of Bearer <token>, noting that <token> represents either an API key or a short-lived access token from Workload Identity Federation. The row for x-api-key states, Legacy fallback for Authorization, still supported. The migration guide's cURL examples, even when sending 2026-10-21, use -H "x-api-key: $ANTHROPIC_API_KEY". Code that constructs HTTP requests without using the SDK can continue to function without changing the key header.

However, there are exceptions for individual SDK clients. The following table lists what the SDK-specific tabs in the migration guide specify.

SDK	Now sent as Authorization: Bearer	Still sent as x-api-key	Already a bearer token before
Python	api_key and ANTHROPIC_API_KEY of Anthropic and AsyncAnthropic; api_key and ANTHROPIC_AWS_API_KEY of AnthropicAWS	AnthropicFoundry	AnthropicBedrockMantle
TypeScript	apiKey, ANTHROPIC_API_KEY; apiKey and ANTHROPIC_AWS_API_KEY in @anthropic-ai/aws-sdk	apiKey in @anthropic-ai/foundry-sdk (as X-Api-Key)	apiKey in @anthropic-ai/bedrock-sdk
C#	ApiKey on AnthropicClient and ClientOptions, ANTHROPIC_API_KEY; ApiKey in AwsClientOptions in the Anthropic.Aws release that depends on v13	AnthropicFoundryApiKeyCredentials	ApiKey in MantleAwsClientOptions
Go	option.WithAPIKey, ANTHROPIC_API_KEY; APIKey in aws.ClientConfig	APIKey in foundry.ClientConfig (as X-Api-Key)	APIKey in bedrock.MantleClientConfig
Java	apiKey on the AnthropicOkHttpClient, AnthropicOkHttpClientAsync, and AnthropicBackend builders, ANTHROPIC_API_KEY	apiKey on the FoundryBackend builder	apiKey on the AwsBackend, BedrockBackend, and BedrockMantleBackend builders
PHP	apiKey and ANTHROPIC_API_KEY of Anthropic\Client; apiKey and ANTHROPIC_AWS_API_KEY of Anthropic\Aws\Client	Anthropic\Foundry\Client	Anthropic\Bedrock\MantleClient
Ruby	api_key: and ANTHROPIC_API_KEY of Anthropic::Client; api_key: and ANTHROPIC_AWS_API_KEY of Anthropic::AWSClient	No statement found	Anthropic::BedrockMantleClient

The Ruby row reads No statement found because the Ruby tab of the migration guide does not mention a Foundry client.

4.3 Clients Hold Only One Credential

The migration guide states, An API key and an authentication token now share a header, so an SDK client holds one credential. According to the migration guide, earlier versions of the Python, TypeScript, C#, Go, Java, and PHP SDKs sent both an API key and an authentication token, each in its own header, when a client had both. Earlier versions of Ruby sent the key if there was one. In the new versions, passing two fails. The nature of this failure varies depending on the SDK.

SDK	Two credentials passed	Exception to the rule
Python	ValueError from the constructor, copy(), or with_options()	AnthropicAWS takes auth_token next to api_key without an error, and sends the key
TypeScript	TypeError from new Anthropic() or withOptions()	The AWS, Bedrock, and Foundry clients and AnthropicVertex throw an AnthropicError for a credential option they do not authenticate with
C#	ArgumentException when a second one is set	Cloud platform clients keep the credentials they were built with
Go	NewClient returns no error; every request the client makes fails	No statement found
Java	IllegalStateException from build()	No statement found
PHP	\InvalidArgumentException	No statement found
Ruby	ArgumentError from Anthropic::Client.new	The platform clients keep their own rules

The Python tab in the migration guide states: The platform clients keep their own rules. AnthropicAWS takes auth_token next to api_key without an error, and sends the key. The ValueError relates specifically to the Python Anthropic and AsyncAnthropic clients; it does not apply to all clients across all SDKs. The No statement found cells in the table describe the scope of the migration guide; this article read the SDK source only for Python (Section 9.5).

When credentials are not passed directly in the code, the client searches for them in a predetermined order. The Python tab lists this order as: ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN, the profile that ANTHROPIC_PROFILE names, Workload Identity Federation variables, and the active profile on disk, and states that only the first of these that is set is used. The Python, TypeScript, C#, Go, and Ruby tabs say that a warning is logged once when both of the first two are set.

4.4 Request-specific X-Api-Key

The code that changes the key for each request also requires modification. For Python, the migration guide states extra_headers={"X-Api-Key": other_key} no longer replaces the client's key: both keys go out. To send a different key for a single request, use extra_headers={"Authorization": f"Bearer {other_key}"}. The code that removes the key from the request also needs to be updated to remove the Authorization header instead of X-Api-Key. The migration guide includes similar information in tabs for TypeScript, Go, PHP, and Ruby.

4.5 CLI and Logs

The migration guide states regarding the ant CLI: With --debug, the request log now shows Authorization: Bearer <REDACTED> where it showed X-Api-Key: <REDACTED>. The migration guide also states that ant has no flag or environment variable for adding custom headers, so it cannot send X-Api-Key. This sentence is unchanged in the migration guide retrieved again on October 28, 2026. However, the CHANGELOG for ant CLI 2.4.0 lists honor ANTHROPIC_CUSTOM_HEADERS in API requests. No statement was found on whether ant 2.4.0 and later can send X-Api-Key. If --base-url or ANTHROPIC_BASE_URL are pointing to a proxy that reads X-Api-Key, the proxy should be modified to read the Authorization header instead.

Regarding the Ruby SDK, the migration guide states: The SDK drops Authorization when it follows a redirect to another origin, which includes a redirect from http to https on the same host. The key is now dropped there too.

4.6 Python SDK Sampling Parameters

Before the API version change, the Python SDK had already removed temperature, top_p, and top_k from its method arguments. The release notes (August 20, 2026) announced Python SDK v1.0, and the Migrating to v1 section of the Python SDK MIGRATION file states, The sampling parameters are only gone from the method signatures, not from the API: models that predate the change still honour them. That section describes how to pass these parameters using the extra_body field for a pinned model that really needs a sampling setting.

This extra_body method applies to SDK 1.x, specifically with API version 2023-06-01. The Versions page states that for API version 2026-10-21, A request that sends any of them returns a 400 error on every model. Even when included in the request body via extra_body, the parameters are still sent. No statement was found that names the result of using the extra_body method with SDK 2.x, which sends API version 2026-10-21.

4.7 Contract Tables

The following two tables list what the user writes in the SDK and what then happens.

What You Write

Setting	You Set	Allowed Values	If You Set Nothing	Source of the Default
SDK major version	Package version in the manifest	Python below 2.0.0 (2023-06-01) or 2.0.0 and later (2026-10-21), and the matching releases of the other SDKs	The installed version decides the API version	SDK overview
API key	api_key or ANTHROPIC_API_KEY	A Claude API key	The credential precedence order applies	Migration guide
Auth token	auth_token or ANTHROPIC_AUTH_TOKEN	A token	The credential precedence order applies	Migration guide
Per-request key	extra_headers (Python)	Authorization: Bearer <key>	The client's credential	Migration guide
X-Api-Key set by hand	http_client auth (Python), defaultHeaders (TypeScript)	The key	Authorization: Bearer only	Migration guide

The following table lists what happens at each boundary, in the same order as the rows above.

What Happens

Setting	At the Boundary	Where It Shows	No Statement Found
SDK major version	Upgrading changes the API version and the key header together	The anthropic-version and Authorization headers	—
API key	Sent as Authorization: Bearer; Foundry clients still send x-api-key	The headers the proxy or gateway receives	—
Auth token	With an API key in the same client: ValueError (Python), TypeError (TypeScript), and so on	An exception before any request is sent	—
Per-request key	extra_headers={"X-Api-Key": ...} sends both keys	Two credential headers on one request	What the Claude API does with the two
X-Api-Key set by hand	With auth_token in the same client (Section 5.2), the gateway must remove its Authorization header before forwarding	The headers that reach the Claude API	—

5. Gateways and Proxies in Front of the Claude API

This section outlines the changes introduced by the SDK update, as seen through the gateways and proxies positioned before the Claude API. It keeps the statements in the sources apart from readings that put those statements together.

5.1 Proxies That Read X-Api-Key

The migration guide recommends modifying proxies and gateways to use Authorization instead of reading or attaching the X-Api-Key, or to set the key in X-Api-Key again on the SDK side. The Python tab shows how to move the key back with an auth function on the HTTP client.

import httpx2
from anthropic import Anthropic, DefaultHttpxClient

def send_x_api_key(request: httpx2.Request) -> httpx2.Request:
    if request.headers.get("Authorization") == f"Bearer {api_key}":
        del request.headers["Authorization"]
        request.headers["X-Api-Key"] = api_key
    return request

client = Anthropic(api_key=api_key, http_client=DefaultHttpxClient(auth=send_x_api_key))

The migration guide states that this function will work for all requests, including those with retries. The TypeScript tab provides an example showing how to set "X-Api-Key": apiKey and Authorization: null in defaultHeaders.

5.2 A Gateway Token and the Key for the API Behind It

The migration guide also includes configurations that explicitly specify the gateway. The Python tab states: If you relied on sending both, for example a token for a gateway and a key for the API behind it, pass the token as auth_token and set X-Api-Key in default_headers. Have the gateway remove its Authorization header before it forwards the request. The Claude API expects one credential for each request. The TypeScript, C#, Go, Java, and PHP tabs show the same configuration.

In this configuration, the gateway receives the token via the Authorization header and the Claude API key via the X-Api-Key header. The gateway should remove the Authorization header before sending the request to the Claude API.

5.3 The Headers That AWS Front Ends Read

AWS documentation states that the gateway and load balancer interpret headers as follows:

• API Gateway API Key: The documentation for receiving API keys states that You distribute API keys to your customers and require them to pass the API key as the X-API-Key header of each incoming request. This applies to the HEADER method. In the AUTHORIZER method, the Lambda authorizer returns the API key.
• API Gateway Token Authorizer: The documentation for the Lambda authorizer states, A TOKEN authorizer receives the caller's identity in a bearer token, such as a JSON Web Token (JWT) or an OAuth token.
• HTTP API Lambda Authorizer: The table describing identity sources states that Header names are case-insensitive. If a request does not include the specified identity source, API Gateway will not invoke the authorizer, and the client will receive a 401 error.
• Application Load Balancer: The documentation for listener rule conditions states that for the http-header condition, The header name and the match evaluation are not case-sensitive.
• AWS WAF: Regarding configurations that inspect a single header, the documentation states, The string match for the name is not case sensitive and is performed after trimming leading and trailing spaces from both the request header and the rule.

5.4 What Can Be Understood by Combining Sentences from Two Documents

This section presents an interpretation derived not from the individual sentences in the sources, but from combining sentences from Sections 5.1 through 5.3. The demonstration in Section 9 did not include a configuration with API Gateway.

The first is the API key of API Gateway. In SDK 1.x, the API key was sent using the X-Api-Key header. In a case-insensitive header environment, this header is the same as X-API-Key, which is the header the API Gateway uses to read the API key. With SDK 1.x, a configuration that put the API Gateway's API key in the SDK's api_key, and had the gateway attach the Claude API key behind it, sent the X-API-Key header. SDK 2.x, on the other hand, sends the same value using Authorization: Bearer. The documentation on API Gateway API keys states that when a usage plan is associated with an API and API keys are enabled on a method, the API Gateway returns a 403 Forbidden error for requests where the key does not match the key associated with the usage plan. Combining these two points, it can be understood that this configuration may result in 403 errors after updating the SDK.

The second is the TOKEN authorizer. The TOKEN authorizer receives a bearer token from a specified header. If that header is Authorization, it becomes the same header used by the new SDK to send the API key. It is not possible to include two different credentials in a single header. The configuration from the migration guide in Section 5.2 (the token in Authorization and the key in X-Api-Key) fits this.

This article does not write these two readings as statements of the sources. To verify this, check your own API Gateway configuration by sending requests from both older and newer versions of the SDK, and compare the results.

5.5 Logged Headers

Logs and filters in front of the API also see a different header.

• The output of the ant CLI with the --debug flag changes from X-Api-Key: <REDACTED> to Authorization: Bearer <REDACTED> (Section 4.5).
• The migration guide instructs you to modify the log filters that read the X-Api-Key within your programs (Section 4.2).
• The AWS WAF API Reference documentation for LoggingConfiguration states regarding RedactedFields: You can specify only the following fields for redaction: UriPath, QueryString, SingleHeader, and Method. The AWS WAF Developer Guide's page on log fields describes headers as The list of headers. No statement was found that names whether WAF logs record the Authorization header.
• The Amazon Bedrock API keys page states: API keys are passed as authorization headers and are not logged. This refers to information regarding CloudTrail.

5.6 Contract Tables

The following two tables outline what the user will write and the corresponding events that will occur.

What You Write

Setting	You Set	Allowed Values	If You Set Nothing	Source of the Default
Proxy that reads X-Api-Key	The proxy's own code or configuration	X-Api-Key or Authorization	Reads what it was written to read	No statement found
SDK sending X-Api-Key	http_client auth (Python), defaultHeaders (TypeScript), and the other SDKs' forms	The key	Authorization: Bearer	Migration guide
Gateway token and API key	auth_token plus X-Api-Key in default_headers (Python)	A gateway token and a Claude API key	Not applicable	Migration guide
API Gateway API key source	apiKeySource on the REST API	HEADER, AUTHORIZER	No statement found	API Gateway API key source page
Header condition	ALB http-header rule condition, WAF single header	A header name and values	Not applicable	No statement found

The following table lists what happens at each boundary, in the same order as the rows above.

What Happens

Setting	At the Boundary	Where It Shows	No Statement Found
Proxy that reads X-Api-Key	The new SDKs send the key in Authorization	What the proxy logs or rejects	—
SDK sending X-Api-Key	The Claude API accepts a key in either header	The headers that reach the Claude API	—
Gateway token and API key	The gateway removes Authorization before forwarding	One credential per request at the Claude API	—
API Gateway API key source	HEADER reads X-API-Key; with API keys enabled on the method, a request whose key does not match the usage plan receives 403	403 Forbidden from API Gateway	How API Gateway treats Authorization: Bearer from the new SDKs (Section 5.4 is a reading)
Header condition	Header names match without regard to case	The rule that matched	Whether WAF logs record the Authorization header

6. Amazon Bedrock

This section outlines the scope of API version 2026-10-21 available within Bedrock, and where the API version and the key are sent.

6.1 Anthropic's Pages: On Bedrock, API Version 2026-10-21 Is Only for Claude 4.7 and Later Models

The Warning in the migration guide states, On Amazon Bedrock, 2026-10-21 is available only for Claude 4.7 and later models. For older models, the same Warning says that a call to a model listed on Claude on Amazon Bedrock (Opus 4.6 and earlier) should stay on the SDK version in use today, or, if it sets the API version itself, keep sending the version it sends today. To move those calls to 2026-10-21, first switch them to a Claude 4.7 or later model. The Versions page also states, On Amazon Bedrock, it's available for Claude 4.7 and later models.

The Warning on the page for Claude on Amazon Bedrock (Opus 4.6 and earlier) is more specific. It reads, The latest version of the SDK sends API version 2026-10-21 by default, including through Amazon Bedrock. The ARN-versioned models in the model table on this page don't support 2026-10-21 on Bedrock, and requests to them that send it can return a 400 error. It asks users of the SDK to stay on the current version and to pin it so that a later install does not upgrade it. The same warning concludes, The Boto3 example sets anthropic_version in its request body and isn't affected.

Anthropic's Bedrock documentation is split into two pages. Claude in Amazon Bedrock (Opus 4.7 and later) utilizes the /anthropic/v1/messages Messages API. Claude on Amazon Bedrock (Opus 4.6 and earlier) works with InvokeModel and Converse, called with ARN-versioned model IDs. The latter page lists Claude Opus 4.7, Claude Opus 4.8, and seven Claude 5 and later models as reachable through InvokeModel on bedrock-runtime.

6.2 Three Paths and Where the API Version Is Sent

According to the AWS documentation for the Anthropic Messages API, the paths for calling Claude within Bedrock span two endpoints: bedrock-runtime and bedrock-mantle. The bedrock-runtime endpoint includes both the InvokeModel function and the Anthropic-style path /anthropic/v1/messages. The Python example provided in the AWS documentation sets the base_url of the first-party Anthropic client to https://bedrock-runtime.us-east-1.amazonaws.com/anthropic and passes a short-term bearer token as the api_key.

The following table 6-1 lists the three paths and indicates where the API version and key are transmitted. The row labeled Python SDK 2.3.0 shows the values the SDK source sends.

Setting	bedrock-runtime InvokeModel	bedrock-runtime /anthropic route	bedrock-mantle
Where the version travels	Request body, anthropic_version	Header, anthropic-version	Header, anthropic-version
Value on the AWS pages	bedrock-2023-05-31	2023-06-01	2023-06-01
Value Python SDK 1.17.0 sends	bedrock-2023-05-31 (AnthropicBedrock)	2023-06-01 (Anthropic)	2023-06-01 (AnthropicBedrockMantle)
Value Python SDK 2.3.0 sends	2026-10-21 (AnthropicBedrock)	2026-10-21 (Anthropic)	2026-10-21 (AnthropicBedrockMantle)
Bedrock API key header in the AWS examples	Authorization: Bearer (API key pages; their examples call Converse on bedrock-runtime)	x-api-key (Messages API page)	x-api-key (Messages API page)
Bedrock API key header Python SDK 2.3.0 sends	Authorization: Bearer	Authorization: Bearer	Authorization: Bearer
Models that accept 2026-10-21 (Anthropic pages)	Claude 4.7 and later	Claude 4.7 and later	Claude 4.7 and later

The SDK rows of Table 6-1 come from the following lines of the source. The Python SDK version 1.17.0, specifically the lib/bedrock/_client.py file, puts DEFAULT_VERSION = "bedrock-2023-05-31" into the default of the body's anthropic_version. Similarly, the same file in version 2.3.0 uses options.json_data.setdefault("anthropic_version", ANTHROPIC_API_VERSION) to set it to 2026-10-21. The lib/bedrock/_mantle.py file puts "anthropic-version": ANTHROPIC_API_VERSION in the header and sends the key as {"Authorization": f"Bearer {api_key}"}. The first-party Anthropic client used on the /anthropic route sends 2026-10-21 and Authorization: Bearer in 2.3.0, as described in Section 4.

6.3 Where the Sources Disagree

The following table lists areas where there are discrepancies in the documentation regarding Bedrock, as well as the approach taken in this article.

Setting	One source	Another source	How this article writes it
Version in the InvokeModel body	AWS request page: The value must be bedrock-2023-05-31.	Python SDK source (2.3.0) sends 2026-10-21; the migration guide says the SDKs' Bedrock clients send 2026-10-21	The sources disagree; both values are given with their sources
Version header on bedrock-mantle	AWS Messages API page: Set anthropic-version: 2023-06-01 as an HTTP header.	Python SDK source (2.3.0) sends 2026-10-21	The sources disagree; Claude 4.7 and later only for 2026-10-21 (Anthropic)
Bedrock API key header on bedrock-mantle	Anthropic Opus 4.7 and later page: Pass it in the x-api-key header on each request.; the AWS Messages API page example uses x-api-key	Python SDK source (2.3.0) sends Authorization: Bearer; the migration guide says AnthropicBedrockMantle already sent a bearer token; the AWS page Use an Amazon Bedrock API key says You can include the Amazon Bedrock API key in the authorization header for Bedrock API keys in general	The sources disagree; neither says the other header is rejected
Whether AWS accepts 2026-10-21	Anthropic pages: available for Claude 4.7 and later on Bedrock	No statement was found in the Bedrock User Guide, What's New, or the Bedrock Document history	Written as an Anthropic statement only
Claude Haiku 4.5 on bedrock-mantle	The Opus 4.7 and later page lists anthropic.claude-haiku-4-5	2026-10-21 is available only for Claude 4.7 and later models	No statement was found on whether it accepts 2026-10-21
Sampling parameters on Claude Opus 4.7	AWS Claude Opus 4.7 model card: Starting with Claude Opus 4.7, temperature, top_p, and top_k parameters are no longer supported.	Anthropic pages: with 2023-06-01, a non-default value returns 400 on Claude 4.7 and later	Both are given; the AWS sentence names neither an API version nor a value. Section 9.4 records the result in this configuration

No statement was found in which Anthropic's documentation directly states the change in the value of the body's anthropic_version. Three statements come close: the Warning on the Opus 4.6 and earlier page (Section 6.1), the section in the migration guide mentioning including their Amazon Bedrock and Google Cloud clients (Section 4.1), and the Bedrock statement on the Versions page (Section 6.1).

On the AWS side, a statement that 2026-10-21 is accepted was searched for in three sources, the body of the Bedrock User Guide, What's New, and the Document history of the Bedrock User Guide (the entries from October 18 to October 26, 2026), and no statement was found.

6.4 Code That Builds the Request Body with Boto3

Code that builds the invoke_model request body with Boto3 writes anthropic_version itself. The Warning on the Opus 4.6 and earlier page states that this example is not affected. Even when upgrading the Anthropic SDK, the values sent by the Boto3 code remain unchanged.

6.5 Claude Haiku 4.5 on Both Pages

Claude Haiku 4.5 is listed on both of Anthropic's Bedrock pages. The model table on the Opus 4.7 and later page lists anthropic.claude-haiku-4-5 as a model for the Messages API. The model table on the Opus 4.6 and earlier page lists anthropic.claude-haiku-4-5-20251001-v1:0.

The migration guide draws the line by model number: 2026-10-21 is only for Claude 4.7 and later models. No statement was found that names whether anthropic.claude-haiku-4-5, listed on the Opus 4.7 and later page, accepts 2026-10-21 on bedrock-mantle. The results of this configuration will be documented in Section 9.

6.6 Model Lifecycle Dates

Bedrock model lifecycle dates come from the AWS pages. The Anthropic Model deprecations page states, Partner-operated platforms, Amazon Bedrock and Claude Models on Google Cloud (Google managed), set their own retirement schedules, so a model's lifecycle status and dates can differ. The AWS model lifecycle page states, Model lifecycle dates are specific to Amazon Bedrock and may differ from dates published by model providers (such as Anthropic or Cohere).

As of October 27, 2026, the AWS Legacy Models table listed Claude Sonnet 4.5 but did not include Claude Sonnet 4.6, Claude Opus 4.6, or Claude Haiku 4.5. A model missing from the table is not proof that the model is Active.

6.7 Contract Tables

The following two tables list what users will input into Bedrock and the resulting outcomes.

What You Write

Setting	You Set	Allowed Values	If You Set Nothing	Source of the Default
anthropic_version (body)	InvokeModel body (Boto3 or the SDK)	AWS pages: bedrock-2023-05-31	The SDK fills it: bedrock-2023-05-31 (1.17.0), 2026-10-21 (2.3.0)	Python SDK source (2.3.0)
anthropic-version (header)	bedrock-mantle or the bedrock-runtime /anthropic route	AWS pages: 2023-06-01	The SDK fills it with its API version	Python SDK source (2.3.0)
Model	modelId or model	Claude 4.7 and later for 2026-10-21 (Anthropic)	Not applicable	Migration guide
Bedrock API key	x-api-key or Authorization	A short-term or long-term Amazon Bedrock API key	Without api_key, the SDK reads AWS_BEARER_TOKEN_BEDROCK (the bedrock-mantle client also reads ANTHROPIC_AWS_API_KEY); without either, it resolves AWS credentials and signs with SigV4	Python SDK source (2.3.0)
SDK version	Package version	Python kept below 2.0.0, and the matching releases, for older models (Anthropic)	The latest version is installed unless pinned	Migration guide

The following table lists what happens at each boundary, in the same order as the rows above.

What Happens

Setting	At the Boundary	Where It Shows	No Statement Found
anthropic_version (body)	2026-10-21 to an ARN-versioned model can return 400 (Anthropic)	The InvokeModel error	An AWS statement that the body accepts 2026-10-21
anthropic-version (header)	2026-10-21 only for Claude 4.7 and later (Anthropic)	The response status	An AWS statement that the header accepts 2026-10-21
Model	Claude Haiku 4.5 is on both Anthropic Bedrock pages	The response status	Whether anthropic.claude-haiku-4-5 accepts 2026-10-21
Bedrock API key	The sources name x-api-key and Authorization: Bearer	The response status	Which header each route rejects
SDK version	Unpinned installs upgrade every call through that SDK	The version each request carries	—

7. Claude Platform on AWS and the Admin API

This section covers Claude Platform on AWS, and the response fields of the Admin API and the Claude Enterprise Analytics API.

7.1 Claude Platform on AWS

The Versions page lists Claude Platform on AWS among the places where API version 2026-10-21 is available. Anthropic's Model deprecations page lists Claude Platform on AWS as an Anthropic-operated platform, noting that the dates listed on that page apply to that location.

Regarding key headers, Anthropic's Claude Platform on AWS page states, in its credential precedence list, that api_key and ANTHROPIC_AWS_API_KEY go out in the Authorization: Bearer header. The AWS Claude Platform on AWS User Guide states, The Anthropic SDK sends the key as a bearer token to the Claude Platform on AWS endpoint; IAM authorizes the request through the aws-external-anthropic:CallWithBearerToken action. The migration guide lists api_key and ANTHROPIC_AWS_API_KEY for AnthropicAWS as having been changed to use the Authorization: Bearer format.

Conversely, the request examples on Anthropic's page and the AWS user guide are signed with SigV4 and include anthropic-version: 2023-06-01. This article does not consider this a discrepancy in documentation. The examples are written using API version 2023-06-01.

Anthropic's page states, The SDK client for Claude Platform on AWS is in beta.

7.2 Admin API and Claude Enterprise Analytics API

In API version 2026-10-21, the old names of renamed fields are removed from the responses of the Admin API and Claude Enterprise Analytics API. This will not result in errors; fields will simply no longer be present. The following table combines the tables in the migration guide.

API	Endpoints	Field removed in 2026-10-21	Read instead
Admin API	RBAC groups: create, list, retrieve, and update	roles	role_ids
Admin API	RBAC group members: list and add, and the response to removing a member	group_id	rbac_group_id
Admin API	RBAC roles: list and retrieve	name	display_name
Admin API	Organization and workspace rate limits: list, and the response to setting a workspace's rate limits	group_type	group.type
Admin API	API keys: list, retrieve, and update	workspace_id	scope (different values)
Claude Enterprise Analytics API	Per-user usage and cost reports	actor.email	actor.email_address
Claude Enterprise Analytics API	Activity summaries	summaries	data

The workspace_id associated with API keys cannot simply be renamed. According to the migration guide, in API version 2023-06-01, the workspace_id for API keys will be null for both keys associated with the Default Workspace and keys not associated with any specific workspace. In API version 2026-10-21, for a key bound to a workspace, scope.workspace_id holds the real ID, including for the Default Workspace. An all-workspaces key has {"type": "organization"} and no workspace_id. Code that previously treated null as the Default Workspace should be modified to compare against the Default Workspace's ID. The migration guide specifies that this ID can be retrieved by using the List Workspaces endpoint with the include_default=true parameter, and then selecting the workspace named "Default".

The migration guide also states, The group_type query parameter on the rate-limit list endpoints and the workspace_id filter on the API key list endpoint are unchanged. These query parameters remain unchanged.

8. Retaining Requests for API Version 2023-06-01

This section outlines what documentation specifies regarding requests, and what it does not, when retaining them for the older API version 2023-06-01.

8.1 The Choices the Migration Guide Gives

The migration guide writes about keeping requests on API version 2023-06-01 in two places:

• Requests that rely on sampling values other than the default: either stop sending the parameter, or keep that request on 2023-06-01. (Section 3.2)
• Older Bedrock models: either remain on the current SDK version, or if you are manually specifying the API version, continue using the current value (see Section 6.1). The Opus 4.6 and earlier page asks you to pin the version so that a later install does not upgrade it.

According to the SDK overview, there is one API version associated with each major SDK version. By pinning one SDK's version, all calls made through that SDK will remain on that API version.

8.2 API Version Guarantees and Recommendations

Under For any given API version, Anthropic preserves:, the Versions page lists existing input parameters and existing output parameters. Conversely, the same page lists what Anthropic may change, which the guarantee does not cover, including optional input additions, additional output values, Change conditions for specific error types, and additions to enumerated output values.

Regarding recommendations, the Versions page states, Anthropic recommends using the latest API version whenever possible. This article quotes the recommendation as a statement of the source and goes no further.

8.3 The Retirement Date of the Older API Version

No statement was found that gives a retirement date, an end date, or a deprecation notice for 2023-06-01. Six pages were searched (the Versions page, the migration guide, the Model deprecations page, the release notes, the SDK overview, and the API overview) with the terms 2023-06-01, deprecat, retire, sunset, and end of. AWS What's New was also searched. This article does not state a date when older API versions will be discontinued, nor does it state that they will not be discontinued.

8.4 What to Pin

The following table lists what to pin to keep requests on API version 2023-06-01.

What to keep	How	Source
SDK major version	Pin the package below the first release that sends 2026-10-21 (Python below 2.0.0, TypeScript below 1.0.0, and so on)	Migration guide, Bedrock Opus 4.6 and earlier page
Separate platform packages	TypeScript: earlier versions of @anthropic-ai/bedrock-sdk and the other platform packages need a version of @anthropic-ai/sdk below 1	Migration guide
Version on raw HTTP	Keep sending anthropic-version: 2023-06-01	Migration guide
Version in a Boto3 body	Keep the anthropic_version value the code writes	Bedrock Opus 4.6 and earlier page
ant CLI	The old go install path keeps installing the latest v1 release; the Homebrew command does not change and upgrades	Migration guide

The CLI tab in the migration guide states, The old path keeps installing the latest v1 release, with no error or warning. If the go install path is not changed, the CLI will remain on v1. However, the same tab states, The Homebrew command and the release downloads stay the same. This article reads this as Homebrew and the release downloads moving to 2.0.0 through the same steps.

9. What This Configuration Recorded

This section describes what was recorded in the requests sent for this article from a local machine and in the US East (N. Virginia) Region. The values presented here reflect the data collected during this particular configuration and on this specific day, and do not represent guaranteed values provided by the documentation. Performance comparisons or assessments cannot be drawn from this data.

9.1 Configuration

No AWS resources were created. The requests were sent on October 27, 2026 (UTC), in the following stages. The first run was sent between 08:03 and 08:04, and the verification (r1) was sent at 08:14.

• s1: Python SDK versions 1.17.0 and 2.3.0 clients were directed to a logging HTTP server running on 127.0.0.1 on the local machine. Dummy values were used for keys and tokens, and the logging server recorded the data after masking the values in the authentication headers.
• s3 and r1: Requests were sent to the Claude API using HTTP, without the SDK. These requests included two API versions, three different temperature settings (omitted, 1, and 0.2), and two models (Claude Sonnet 4.6 and Claude Haiku 5.5). Both document and citations were included in requests for both the Messages API and token count measurements.
• s4 and r1: Requests were sent to Bedrock, specifically to bedrock-runtime's InvokeModel (using SigV4), the /anthropic route within bedrock-runtime, and to bedrock-mantle. These requests included values for two API versions and were directed to Claude 4.6 and earlier models (Claude Sonnet 4.6 and Claude Haiku 4.5) and to Claude Opus 4.7. Short-term Bedrock bearer tokens, valid for 15 minutes, were sent using both x-api-key and Authorization: Bearer headers.
• s6: Using Python SDK versions 1.17.0 and 2.3.0, Claude Sonnet 4.6 and Claude Opus 4.7 were called through Anthropic (the /anthropic route) and AnthropicBedrock, and Claude Opus 4.7 and Claude Haiku 4.5 through AnthropicBedrockMantle (Section 9.4).

The max_tokens value was set to 16. Only the status code, error type, and error message were recorded. The response body and speed were not recorded.

In the first run, the raw HTTP requests to bedrock-mantle and the s6 requests to bedrock-mantle with SDK 1.17.0 all returned a 403 error, with the message Your subscription to the model is being set up. Check your Marketplace subscriptions page to confirm. Thirteen seconds after the s6 requests with SDK 1.17.0, the requests with SDK 2.3.0 returned 200. This article uses the records from r1, rather than the first run's raw HTTP records and SDK 1.17.0 records for bedrock-mantle.

9.2 What the SDKs Sent

The following table shows the header and body values received by the logging server in s1.

Client and credential	Python SDK 1.17.0	Python SDK 2.3.0
Anthropic, api_key	x-api-key; anthropic-version: 2023-06-01	Authorization: Bearer; anthropic-version: 2026-10-21
Anthropic, auth_token	Authorization: Bearer; 2023-06-01	Authorization: Bearer; 2026-10-21
Anthropic, api_key and auth_token	Both x-api-key and Authorization: Bearer	ValueError before any request
Anthropic, extra_headers={"X-Api-Key": ...}	One x-api-key (the per-request key replaced the client's)	Authorization: Bearer and x-api-key
AnthropicBedrock, SigV4	Body anthropic_version: bedrock-2023-05-31	Body anthropic_version: 2026-10-21
AnthropicBedrock, api_key	Authorization: Bearer; body bedrock-2023-05-31	Authorization: Bearer; body 2026-10-21
AnthropicBedrockMantle, api_key	Authorization: Bearer; 2023-06-01	Authorization: Bearer; 2026-10-21
AnthropicAWS, api_key	x-api-key; 2023-06-01	Authorization: Bearer; 2026-10-21
AnthropicAWS, api_key and auth_token	Both x-api-key and Authorization: Bearer	Authorization: Bearer only; no error
AnthropicFoundry, api_key	x-api-key and api-key; 2023-06-01	x-api-key and api-key; 2026-10-21

The values in this table align with the information presented in Sections 4 and 6. Microsoft Foundry clients included the key in two headers: x-api-key and api-key, in both versions. The Claude in Microsoft Foundry page states, Use either the api-key or x-api-key header in your requests, or provide it to the SDK.

9.3 What the Claude API Returned

The following table shows the status codes returned by the Claude API for s3 and r1.

Request	2023-06-01	2026-10-21
Claude Sonnet 4.6 or Claude Haiku 5.5, sampling parameters omitted	200	200
Claude Sonnet 4.6, temperature: 1	200	400
Claude Sonnet 4.6, temperature: 0.2	200	400
Claude Haiku 5.5, temperature: 1	200	400
Claude Haiku 5.5, temperature: 0.2	400	400
Key in Authorization: Bearer	200	200
document block directly in an assistant message	200	400
text block with citations in a user message, after a user message that holds the document	200	400
Token counting, document block directly in an assistant message	200	400
Token counting, text block with citations in a user message	200	400

The error messages for the 400 status codes were as follows. The first line indicated a 400 error for temperature on 2026-10-21, and this was consistent across all models. The second line indicated a 400 error for Claude Haiku 5.5 with temperature: 0.2 on 2023-06-01. The third and fourth lines indicated 400 errors for document and citations on 2026-10-21. The error messages for document and citations specifically mentioned the location of the block.

temperature: Extra inputs are not permitted
`temperature` is deprecated for this model.
messages: `document` blocks can't be placed directly in `assistant` messages; send them in a `user` message. Found at: messages.1.content.0
messages: text blocks in `user` messages can't have `citations`; remove `citations` from them. Found at: messages.2.content.0

The 2026-10-21 column of this table matches the statements in Section 3. Of the entries in the 2023-06-01 column, the four rows marked No statement found (the default value on Claude 4.7 and later models, document, citations, and token counting) returned 200 in this configuration. However, the default-value row was recorded only with Claude Haiku 5.5, which has a unique rule, as documented in the published LLM API Parameter Compatibility Reference, and only accepts the temperature parameter with a value of 1. Based on one record for Claude Haiku 5.5, it is not possible to determine the overall behavior of Claude 4.7 and later models.

In s3, temperature: 1 was also sent to token counting. The request returned 400 on both API versions, with the message temperature: Extra inputs are not permitted. In this configuration, token counting did not accept temperature on 2023-06-01 either.

9.4 What Bedrock Returned

The following table shows the status codes returned by Bedrock in s4 and r1. The bedrock-mantle column shows the records from r1.

Request	bedrock-runtime InvokeModel	bedrock-runtime /anthropic route	bedrock-mantle
Earlier version value, sampling parameters omitted, Claude Sonnet 4.6 or Claude Haiku 4.5	200	200 (Claude Sonnet 4.6)	200 (Claude Haiku 4.5)
2026-10-21, sampling parameters omitted, Claude Sonnet 4.6 or Claude Haiku 4.5	200	200 (Claude Sonnet 4.6)	200 (Claude Haiku 4.5)
2026-10-21, sampling parameters omitted, Claude Opus 4.7	200	200	200
2026-10-21, temperature: 1, Claude Sonnet 4.6 or Claude Haiku 4.5	400	400 (Claude Sonnet 4.6)	400 (Claude Haiku 4.5)
2026-10-21, temperature: 1, Claude Opus 4.7	400	400	400
Earlier version value, temperature: 0.2, Claude Sonnet 4.6 or Claude Haiku 4.5	200 (Claude Sonnet 4.6)	200 (Claude Sonnet 4.6)	200 (Claude Haiku 4.5)
Earlier version value, temperature: 1, Claude Opus 4.7	200	200	200
Bearer token in x-api-key	403	200	200
Bearer token in Authorization: Bearer	200	200	200

In the table, Earlier version value means bedrock-2023-05-31 in the body for InvokeModel and 2023-06-01 in the header for the other two paths. On all three paths, the message of the 400 for temperature on 2026-10-21 was temperature: Extra inputs are not permitted. The message of the 403 for x-api-key on InvokeModel was Authorization header is missing.

In s6, Python SDK 1.17.0 and 2.3.0 called Claude Sonnet 4.6 and Claude Opus 4.7 through Anthropic (the /anthropic route) and AnthropicBedrock, and Claude Opus 4.7 and Claude Haiku 4.5 through AnthropicBedrockMantle. No sampling parameters were sent. The six calls with SDK 1.17.0 in r1 and the six calls with SDK 2.3.0 in the first run all returned 200.

9.5 Things That Cannot Be Determined Based on This Configuration

Putting the records of this configuration next to the statements in Section 6 gives the following readings. However, it is important to note that the following points cannot be definitively determined based solely on this configuration and its associated logs.

• The Warning on the Opus 4.6 and earlier page states that sending API version 2026-10-21 to an ARN-versioned model can return a 400 error. In this configuration, requests sent to Claude Sonnet 4.6 and Claude Haiku 4.5 with API version 2026-10-21 returned a 200 status code if no sampling parameters were included, but a 400 error if the temperature parameter was included. It is impossible to determine whether this behavior would be consistent across other models, different regions, or with different functionalities, or on subsequent dates. This article writes the statement in the source (can return a 400 error) as the one to follow.
• The anthropic.claude-haiku-4-5 model on bedrock-mantle accepted API version 2026-10-21 in this configuration. However, no corresponding statement was found in the documentation (see Section 6.5).
• While the AWS pages give bedrock-2023-05-31 as the value for the InvokeModel body, this configuration also accepted the value 2026-10-21 for the API version, and the temperature rule was the rule of API version 2026-10-21. No corresponding statement was found in the AWS documentation (see Section 6.3).
• The InvokeModel function within bedrock-runtime did not accept a bearer token using the x-api-key header. While the AWS API key documentation provides an example using Authorization: Bearer, no statement was found confirming that x-api-key is not accepted.
• This configuration has not been tested with API Gateway, Application Load Balancer, or AWS WAF. The interpretation presented in Section 5.4 has also not been verified within this configuration.
• Only the Python SDK had its source read and its requests recorded. For the other SDKs, this article follows the migration guide, as in Section 4.

10. Failure Modes

This section lists the failures that an API version migration can cause, with where each one shows.

Symptom	Cause	Where it shows	Section
400 on a request that sends temperature: 1	2026-10-21 removes the sampling parameters, even at the default	400 invalid_request_error	3.1
A Claude 4.6 call loses its lower temperature	The parameter was removed to pass on 2026-10-21	Output that samples with the defaults	3.3
400 on a conversation that replays a document	A document block directly in an assistant message	400 invalid_request_error	3.1
400 when one agent's cited output is passed to another	A text block with non-empty citations in a user message	400 invalid_request_error	3.1
A proxy rejects or misses the key after the SDK upgrade	The key moved from X-Api-Key to Authorization	The proxy's log or response	4.2, 5.1
ValueError when the client is built	An API key and an auth token passed to one Python client	An exception before any request	4.3
Two keys on one request	extra_headers={"X-Api-Key": ...} no longer replaces the client's key	The headers the gateway receives	4.4
400 from an older model on Bedrock after the SDK upgrade	The SDK sends 2026-10-21 to an ARN-versioned model, which the Opus 4.6 and earlier page says can return 400	The Bedrock error	6.1
Boto3 calls and SDK calls behave differently	Boto3 writes anthropic_version itself; the SDK fills it	The version each request carries	6.4
Code reads null where it read a workspace ID	workspace_id removed from API keys in 2026-10-21	A missing field, no error	7.2
Every call moves to 2026-10-21 after a rebuild	The SDK was not pinned	The version each request carries	8.1

11. Frequently Asked Questions about API Version 2026-10-21 on AWS

This section answers frequently asked questions, referencing the sections within this document.

Q1. If temperature is sent at its default value of 1, does the request avoid a 400?

On 2026-10-21, the request returns 400. The migration guide states even at the parameter's default value, and the Versions page states on every model. With 2023-06-01, the Model deprecations page names a 400 only for values other than the default on Claude 4.7 and later models and Claude Mythos Preview, and Claude 4.6 and earlier models accept other values too (Section 3.2).

Q2. Will temperature continue to be available with Claude Sonnet 4.6?

As long as you are using API version 2023-06-01, you can continue to use the temperature parameter; with Python SDK 1.x, it is passed through extra_body (Section 4.6). However, with API version 2026-10-21, a request that sends temperature returns 400, even with Claude Sonnet 4.6. The migration guide advises that when dealing with requests that rely on values other than the default, you should either stop sending the parameter or keep those requests using API version 2023-06-01. (See Sections 3.2 and 8.1).

Q3. After an SDK upgrade, which header carries the API key?

For many clients, it goes out as Authorization: Bearer. Microsoft Foundry clients continue to use x-api-key, and the Bedrock Mantle clients already sent a bearer token. The Claude API accepts keys in either header (see Section 4.2).

Q4. Can one client be given both an API key and an authentication token?

In the new SDKs, a client cannot be given both an API key and an authentication token. The way failures are reported varies depending on the SDK; for example, Python's Anthropic raises a ValueError, while TypeScript throws a TypeError. Python's AnthropicAWS is an exception: it accepts both and sends the key. If you need to send both the gateway token and the API key, use the configuration outlined in the migration guide (passing the token in the Authorization header and the key in the X-Api-Key header, with the gateway stripping the Authorization header). See Sections 4.3 and 5.2.

Q5. Even with Bedrock, will using the new SDK result in behavior consistent with API version 2026-10-21?

Anthropic's documentation states that API version 2026-10-21 is available only for Claude 4.7 and later models. However, a request that sends API version 2026-10-21 to an ARN-versioned model listed on the Opus 4.6 and earlier page can return 400. No statement was found in the AWS documentation that API version 2026-10-21 is accepted. In this configuration (Section 9.4), Claude Sonnet 4.6 and Claude Haiku 4.5 also returned 200 on 2026-10-21 when no sampling parameters were sent, and 400 when temperature: 1 was sent. This is a record, not a statement in the sources (see Sections 6.1, 6.3, and 9.5).

Q6. Which value for the API version being sent to Bedrock is correct?

This article does not provide a definitive answer. The AWS documentation specifies bedrock-2023-05-31 in the body of the InvokeModel request and 2023-06-01 in the header. The source code for the Python SDK version 2.3.0 includes 2026-10-21 in both locations. As a place where the sources disagree, both values are given with their sources (Section 6.3).

Q7. Does code that calls InvokeModel with Boto3 need any changes?

The Warning on the Opus 4.6 and earlier page states that the Boto3 example is not affected because it writes anthropic_version in its request body. Even with updates to the Anthropic SDK, the values sent by the Boto3 code remain unchanged (Section 6.4).

Q8. When will API version 2023-06-01 be discontinued?

No statement was found that gives the date. The migration guide gives the option of keeping requests on API version 2023-06-01. The Versions page recommends using the latest API version (see Sections 8.2 and 8.3).

12. Summary

Migrating to API version 2026-10-21 may appear to be a simple SDK version upgrade, but it involves simultaneous changes to the API version, the model, the path, and the headers.

• Whether a 400 error is returned depends on the API version and model. With 2026-10-21, requests that include temperature, top_p, or top_k will return a 400 error, even with default values, regardless of the model. In contrast, with 2023-06-01, Claude 4.7 and later models and Claude Mythos Preview return a 400 error for values other than the defaults.
• In 2026-10-21, a document block placed directly in an assistant message and a text block with non-empty citations in a user message also return a 400 error. This also affects token counting and applies to Message Batches created with 2026-10-21.
• The new SDK sends the API key using the Authorization: Bearer header (the Microsoft Foundry client still sends x-api-key). While the Claude API accepts both headers, proxies and gateways that read the X-Api-Key header will require modifications. A client holds one credential.
• The overlap with an API Gateway API key or a TOKEN authorizer is a reading of two statements, not a statement in the sources. Check it in your own configuration.
• Anthropic's documentation states that, in Bedrock, 2026-10-21 is available only for Claude 4.7 and later models. In this configuration, Claude Sonnet 4.6 and Claude Haiku 4.5 also accepted it when no sampling parameters were sent (Section 9.5). For older models, Anthropic's pages say to keep the SDK on the version used today and pin it. There are discrepancies between the API version values and key header information as documented in AWS and the SDK source code.
• Anthropic's Versions page lists Claude Platform on AWS as supporting 2026-10-21, and the SDK sends the key as a bearer token. The SDK client is currently in beta.
• In 2026-10-21, obsolete field names are removed from the Admin API responses, and for the API key's workspace_id, the code reads scope.
• No statement was found that gives a retirement date for 2023-06-01.

13. References

• Anthropic: Migrating to API version 2026-10-21
• Anthropic: Versions
• Anthropic: Claude Platform release notes
• Anthropic: API overview
• Anthropic: Claude API errors
• Anthropic: Model deprecations
• Anthropic: SDKs, CLI, and libraries
• Anthropic: Claude in Amazon Bedrock (Opus 4.7 and later)
• Anthropic: Claude on Amazon Bedrock (Opus 4.6 and earlier)
• Anthropic: Claude Platform on AWS
• Anthropic: Claude in Microsoft Foundry
• Anthropic: Batch processing
• Anthropic: Using the Messages API
• Anthropic SDK for Python: CHANGELOG
• Anthropic SDK for Python: MIGRATION
• Anthropic SDK for Python: src/anthropic/lib/bedrock/_client.py
• Anthropic SDK for Python: src/anthropic/lib/bedrock/_mantle.py
• Amazon Bedrock User Guide: Inference using Anthropic Messages API
• Amazon Bedrock User Guide: Request and Response
• Amazon Bedrock User Guide: API keys
• Amazon Bedrock User Guide: Use an Amazon Bedrock API key
• Amazon Bedrock User Guide: Model lifecycle
• Amazon Bedrock User Guide: Model lifecycle (Legacy)
• Amazon Bedrock User Guide: Document history for the Amazon Bedrock User Guide
• Amazon Bedrock User Guide: Claude Opus 4.7
• Claude Platform on AWS User Guide: Authentication
• Claude Platform on AWS User Guide: Making requests
• API Gateway Developer Guide: Choose an API key source in API Gateway
• API Gateway Developer Guide: Use API Gateway Lambda authorizers
• API Gateway Developer Guide: Control access to HTTP APIs with AWS Lambda authorizers
• Elastic Load Balancing: Condition types for listener rules
• AWS WAF Developer Guide: Request components in AWS WAF
• AWS WAF Developer Guide: Log fields for protection pack (web ACL) traffic
• AWS WAF API Reference: LoggingConfiguration

References:
Tech Blog with curated related content