One read of Claude Developer Platformapi-20261023T000722Z
139 pages moved out of 812 read.
What this read moved
1-25 of 139, page 1 of 6This capture is too large to show at once. Changes 1-25 of 139 are below, significant first; the rest are on the following screens.
about-claude/models/optimizing-for-cost-and-intelligence Changed · +19 / -20 lines
about-claude/use-case-guides/content-moderation Changed · +130 / -130 lines
about-claude/use-case-guides/customer-support-chat Changed · +24 / -24 lines
about-claude/use-case-guides/legal-summarization Changed · +75 / -75 lines
about-claude/use-case-guides/ticket-routing Changed · +6 / -2 lines
agents-and-tools/mcp-connector Changed · +29 / -27 lines
agents-and-tools/tool-use/advisor-tool Changed · +38 / -20 lines
agents-and-tools/tool-use/bash-tool Changed · +21 / -19 lines
agents-and-tools/tool-use/browser-use-tool Changed · +28 / -20 lines
agents-and-tools/tool-use/build-a-tool-using-agent Changed · +61 / -61 lines
agents-and-tools/tool-use/computer-use-tool Changed · +32 / -24 lines
agents-and-tools/tool-use/fine-grained-tool-streaming Changed · +18 / -18 lines
agents-and-tools/tool-use/memory-tool Changed · +36 / -36 lines
agents-and-tools/tool-use/overview Changed · +7 / -7 lines
agents-and-tools/tool-use/parallel-tool-use Changed · +10 / -6 lines
agents-and-tools/tool-use/programmatic-tool-calling Changed · +105 / -104 lines
agents-and-tools/tool-use/server-tools Changed · +14 / -9 lines
agents-and-tools/tool-use/text-editor-tool Changed · +170 / -170 lines
agents-and-tools/tool-use/tool-runner Changed · +52 / -50 lines
agents-and-tools/tool-use/web-fetch-tool Changed · +8 / -4 lines
agents-and-tools/tool-use/web-search-tool Changed · +3 / -3 lines
api/beta-headers Changed · +6 / -6 lines
api/claude-models-on-google-cloud-anthropic-managed-iam-permissions New page · 244 lines, new page
## Service details ## Predefined roles ## Permissions ### Messages ### Message batches ### Models ### Files ### Skills ### Agents ### Sessions ### Environments ### Vaults ### Memory stores ### Deployments ### Dreams ### Encryption keys ### Usage reports ## See also
A whole new page. There's nothing to diff it against, so here is what it says.
---
title: IAM permissions for Claude Models on Google Cloud (Anthropic managed)
url: https://platform.claude.com/docs/en/api/claude-models-on-google-cloud-anthropic-managed-iam-permissions
description: Look up Google Cloud IAM permissions, predefined roles, and audit log types for Claude Models on Google Cloud (Anthropic managed).
---
Claude Models on Google Cloud (Anthropic managed) uses Google Cloud IAM for access control. Every API route needs one permission from the `claude.googleapis.com` service. If the caller doesn't hold that permission, Google Cloud returns an HTTP 403 error. Three predefined roles bundle the permissions. For setup and authentication, see [Claude Models on Google Cloud (Anthropic managed)](https://platform.claude.com/docs/en/build-with-claude/claude-models-on-google-cloud/anthropic-managed).
## Service details
The following table describes the Google Cloud service for Claude Models on Google Cloud (Anthropic managed).
| Attribute | Value |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Service** | `claude.googleapis.com` |
| **Where permissions are checked** | A workspace or the Anthropic organization |
| **Audit log types** | Data Access, Admin Activity<br />To turn on Data Access logs, see [Monitoring and logging](https://platform.claude.com/docs/en/build-with-claude/claude-models-on-google-cloud/anthropic-managed#monitoring-and-logging). |
Grant roles on the Google Cloud project. For how projects, organizations, and workspaces relate, see [Workspaces](https://platform.claude.com/docs/en/build-with-claude/claude-models-on-google-cloud/anthropic-managed#workspaces).
Permissions on this page are in the short form `resource.verb`, such as `messages.create`.
## Predefined roles
The following table lists the predefined roles for Claude Models on Google Cloud (Anthropic managed).
| Role | Display name | Permissions |
| --------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `roles/claude.viewer` | Claude Viewer | Every `get` and `list` permission on workspace resources. |
| `roles/claude.user` | Claude User | Everything in `roles/claude.viewer`, plus every other permission on workspace resources.<br />For example, `messages.create`, `messages.countTokens`, and `environments.processWork`. |
| `roles/claude.admin` | Claude Admin | Everything in `roles/claude.user`, plus the permissions checked on your Anthropic organization.<br />For example, `externalKeys.*` and `usageAnalytics.list`. |
In the following tables, **Admin**, **User**, and **Viewer** stand for these three roles.
## Permissions
The following tables list 68 permissions across 111 routes.
The `get` and `list` permissions are the read-only ones.
Unless a section says otherwise, each route's audit log type is Data Access.
`roles/claude.viewer` can't send messages or count tokens. Sending a message needs `messages.create`. Counting tokens needs `messages.countTokens`.
Some routes in the following tables might not be available to your organization. To check which features are available, see [Feature support](https://platform.claude.com/docs/en/build-with-claude/claude-models-on-google-cloud/anthropic-managed#feature-support).
### Messages
| Permission | Roles | Routes authorized |
| ---------------------- | ----------- | -------------------------------- |
| `messages.create` | Admin, User | `POST /v1/messages` |
| `messages.countTokens` | Admin, User | `POST /v1/messages/count_tokens` |
### Message batches
| Permission | Roles | Routes authorized |
| ----------------------- | ------------------- | -------------------------------------------------------------------------------------------------------- |
| `messageBatches.create` | Admin, User | `POST /v1/messages/batches` |
| `messageBatches.get` | Admin, User, Viewer | `GET /v1/messages/batches/{message_batch_id}`<br />`GET /v1/messages/batches/{message_batch_id}/results` |
| `messageBatches.list` | Admin, User, Viewer | `GET /v1/messages/batches` |
| `messageBatches.delete` | Admin, User | `DELETE /v1/messages/batches/{message_batch_id}` |
| `messageBatches.cancel` | Admin, User | `POST /v1/messages/batches/{message_batch_id}/cancel` |
`roles/claude.viewer` can read batch results. `messageBatches.get` authorizes both reading a batch's metadata and downloading its results.
### Models
| Permission | Roles | Routes authorized |
| ------------- | ------------------- | --------------------------- |
| `models.get` | Admin, User, Viewer | `GET /v1/models/{model_id}` |
| `models.list` | Admin, User, Viewer | `GET /v1/models` |
### Files
| Permission | Roles | Routes authorized |
| -------------- | ------------------- | ---------------------------------------------------------------- |
| `files.create` | Admin, User | `POST /v1/files` |
| `files.get` | Admin, User, Viewer | `GET /v1/files/{file_id}`<br />`GET /v1/files/{file_id}/content` |
| `files.list` | Admin, User, Viewer | `GET /v1/files` |
| `files.delete` | Admin, User | `DELETE /v1/files/{file_id}` |
`roles/claude.viewer` can download files. `files.get` authorizes both reading a file's metadata and downloading its content.
### Skills
| Permission | Roles | Routes authorized |
| --------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `skills.create` | Admin, User | `POST /v1/skills` |
| `skills.get` | Admin, User, Viewer | `GET /v1/skills/{skill_id}`<br />`GET /v1/skills/{skill_id}/versions`<br />`GET /v1/skills/{skill_id}/versions/{version}`<br />`GET /v1/skills/{skill_id}/versions/{version}/content` |
| `skills.list` | Admin, User, Viewer | `GET /v1/skills` |
| `skills.update` | Admin, User | `POST /v1/skills/{skill_id}/versions`<br />`DELETE /v1/skills/{skill_id}/versions/{version}` |
| `skills.delete` | Admin, User | `DELETE /v1/skills/{skill_id}` |
Creating or deleting a skill version needs `skills.update`, not `skills.create` or `skills.delete`.
### Agents
| Permission | Roles | Routes authorized |
| ---------------- | ------------------- | --------------------------------------------------------------------- |
| `agents.create` | Admin, User | `POST /v1/agents` |
| `agents.get` | Admin, User, Viewer | `GET /v1/agents/{agent_id}`<br />`GET /v1/agents/{agent_id}/versions` |
| `agents.list` | Admin, User, Viewer | `GET /v1/agents` |
| `agents.update` | Admin, User | `POST /v1/agents/{agent_id}` |
| `agents.archive` | Admin, User | `POST /v1/agents/{agent_id}/archive` |
You can archive an agent but not delete it.
### Sessions
| Permission | Roles | Routes authorized |
| ------------------ | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `sessions.create` | Admin, User | `POST /v1/sessions` |
| `sessions.get` | Admin, User, Viewer | `GET /v1/sessions/{session_id}`<br />`GET /v1/sessions/{session_id}/events`<br />`GET /v1/sessions/{session_id}/events/stream`<br />`GET /v1/sessions/{session_id}/resources`<br />`GET /v1/sessions/{session_id}/resources/{resource_id}`<br />`GET /v1/sessions/{session_id}/threads`<br />`GET /v1/sessions/{session_id}/threads/{thread_id}`<br />`GET /v1/sessions/{session_id}/threads/{thread_id}/events`<br />`GET /v1/sessions/{session_id}/threads/{thread_id}/stream` |
| `sessions.list` | Admin, User, Viewer | `GET /v1/sessions` |
| `sessions.update` | Admin, User | `POST /v1/sessions/{session_id}`<br />`POST /v1/sessions/{session_id}/events`<br />`POST /v1/sessions/{session_id}/resources`<br />`POST /v1/sessions/{session_id}/resources/{resource_id}`<br />`DELETE /v1/sessions/{session_id}/resources/{resource_id}` |
| `sessions.archive` | Admin, User | `POST /v1/sessions/{session_id}/archive`<br />`POST /v1/sessions/{session_id}/threads/{thread_id}/archive` |
| `sessions.delete` | Admin, User | `DELETE /v1/sessions/{session_id}` |
`sessions.get` authorizes reading the session, its event history and event stream, its resources, and its threads. As a result, `roles/claude.viewer` can read every session's full event history.
Other session operations need the following permissions:
* Sending events: `sessions.update`
* Adding, changing, or removing session resources: `sessions.update`
* Archiving a thread: `sessions.archive`
### Environments
| Permission | Roles | Routes authorized |
| -------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `environments.create` | Admin, User | `POST /v1/environments` |
| `environments.get` | Admin, User, Viewer | `GET /v1/environments/{environment_id}`<br />`GET /v1/environments/{environment_id}/work`<br />`GET /v1/environments/{environment_id}/work/stats`<br />`GET /v1/environments/{environment_id}/work/{work_id}` |
| `environments.list` | Admin, User, Viewer | `GET /v1/environments` |
| `environments.update` | Admin, User | `POST /v1/environments/{environment_id}` |
| `environments.archive` | Admin, User | `POST /v1/environments/{environment_id}/archive` |
| `environments.delete` | Admin, User | `DELETE /v1/environments/{environment_id}` |
| `environments.processWork` | Admin, User | `GET /v1/environments/{environment_id}/work/poll`<br />`POST /v1/environments/{environment_id}/work/{work_id}`<br />`POST /v1/environments/{environment_id}/work/{work_id}/ack`<br />`POST /v1/environments/{environment_id}/work/{work_id}/heartbeat`<br />`POST /v1/environments/{environment_id}/work/{work_id}/stop` |
`roles/claude.user` and `roles/claude.admin` include every permission that a [self-hosted sandbox](https://platform.claude.com/docs/en/managed-agents/self-hosted-sandboxes) worker needs. `environments.processWork` authorizes these worker actions:
* Polling for work
* Acknowledging work items
* Sending heartbeats for work items
* Stopping work items
* Updating work items
This permission is separate from `environments.update`. Reading the work queue and its statistics needs only `environments.get`.
Besides `environments.processWork`, a worker needs other permissions to run a session, such as `sessions.get` to read the session and its events, `sessions.update` to send tool results, and `skills.get` to download the agent's skills.
### Vaults
Google Cloud records these routes in Admin Activity audit logs, except the route for `vaults.verify`, whose audit log type is Data Access.
| Permission | Roles | Routes authorized |
| ---------------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `vaults.create` | Admin, User | `POST /v1/vaults` |
| `vaults.get` | Admin, User, Viewer | `GET /v1/vaults/{vault_id}`<br />`GET /v1/vaults/{vault_id}/credentials`<br />`GET /v1/vaults/{vault_id}/credentials/{credential_id}` |
| `vaults.list` | Admin, User, Viewer | `GET /v1/vaults` |
| `vaults.update` | Admin, User | `POST /v1/vaults/{vault_id}`<br />`POST /v1/vaults/{vault_id}/credentials`<br />`POST /v1/vaults/{vault_id}/credentials/{credential_id}`<br />`DELETE /v1/vaults/{vault_id}/credentials/{credential_id}` |
| `vaults.archive` | Admin, User | `POST /v1/vaults/{vault_id}/archive`<br />`POST /v1/vaults/{vault_id}/credentials/{credential_id}/archive` |
| `vaults.delete` | Admin, User | `DELETE /v1/vaults/{vault_id}` |
| `vaults.verify` | Admin, User | `POST /v1/vaults/{vault_id}/credentials/{credential_id}/mcp_oauth_validate` |
Credential operations need the following permissions:
* Creating, changing, or deleting a credential: `vaults.update`
* Archiving a credential: `vaults.archive`
* Reading a credential: `vaults.get`
* Checking a stored MCP OAuth credential: `vaults.verify`
With `vaults.get`, `roles/claude.viewer` can list a vault's credentials. Claude Models on Google Cloud (Anthropic managed) never returns a credential's secret fields. To learn more, see [Authenticate with vaults](https://platform.claude.com/docs/en/managed-agents/vaults).
### Memory stores
| Permission | Roles | Routes authorized |
| ---------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `memoryStores.create` | Admin, User | `POST /v1/memory_stores` |
| `memoryStores.get` | Admin, User, Viewer | `GET /v1/memory_stores/{memory_store_id}`<br />`GET /v1/memory_stores/{memory_store_id}/memories`<br />`GET /v1/memory_stores/{memory_store_id}/memories/{memory_id}`<br />`GET /v1/memory_stores/{memory_store_id}/memory_versions`<br />`GET /v1/memory_stores/{memory_store_id}/memory_versions/{memory_version_id}` |
| `memoryStores.list` | Admin, User, Viewer | `GET /v1/memory_stores` |
| `memoryStores.update` | Admin, User | `POST /v1/memory_stores/{memory_store_id}`<br />`POST /v1/memory_stores/{memory_store_id}/memories`<br />`POST /v1/memory_stores/{memory_store_id}/memories/{memory_id}`<br />`DELETE /v1/memory_stores/{memory_store_id}/memories/{memory_id}`<br />`POST /v1/memory_stores/{memory_store_id}/memory_versions/{memory_version_id}/redact` |
| `memoryStores.archive` | Admin, User | `POST /v1/memory_stores/{memory_store_id}/archive` |
| `memoryStores.delete` | Admin, User | `DELETE /v1/memory_stores/{memory_store_id}` |
Memory store operations need the following permissions:
* Reading the store, its memories, or its version history: `memoryStores.get`
* Creating, changing, or deleting a memory: `memoryStores.update`
* Redacting a memory version: `memoryStores.update`
### Deployments
| Permission | Roles | Routes authorized |
| --------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| `deployments.create` | Admin, User | `POST /v1/deployments` |
| `deployments.get` | Admin, User, Viewer | `GET /v1/deployment_runs`<br />`GET /v1/deployment_runs/{deployment_run_id}`<br />`GET /v1/deployments/{deployment_id}` |
| `deployments.list` | Admin, User, Viewer | `GET /v1/deployments` |
| `deployments.update` | Admin, User | `POST /v1/deployments/{deployment_id}` |
| `deployments.archive` | Admin, User | `POST /v1/deployments/{deployment_id}/archive` |
| `deployments.run` | Admin, User | `POST /v1/deployments/{deployment_id}/run` |
| `deployments.pause` | Admin, User | `POST /v1/deployments/{deployment_id}/pause` |
| `deployments.unpause` | Admin, User | `POST /v1/deployments/{deployment_id}/unpause` |
Reading deployment runs needs `deployments.get`.
### Dreams
| Permission | Roles | Routes authorized |
| ---------------- | ------------------- | ------------------------------------ |
| `dreams.create` | Admin, User | `POST /v1/dreams` |
| `dreams.get` | Admin, User, Viewer | `GET /v1/dreams/{dream_id}` |
| `dreams.list` | Admin, User, Viewer | `GET /v1/dreams` |
| `dreams.archive` | Admin, User | `POST /v1/dreams/{dream_id}/archive` |
| `dreams.cancel` | Admin, User | `POST /v1/dreams/{dream_id}/cancel` |
Dreams is a research preview feature. To request access, see [Dreams](https://platform.claude.com/docs/en/managed-agents/dreams).
### Encryption keys
Google Cloud records these routes in Admin Activity audit logs.
| Permission | Roles | Routes authorized |
| --------------------- | ----- | ---------------------------------------------------------- |
| `externalKeys.create` | Admin | `POST /v1/organizations/external_keys` |
| `externalKeys.get` | Admin | `GET /v1/organizations/external_keys/{external_key_id}` |
| `externalKeys.list` | Admin | `GET /v1/organizations/external_keys` |
| `externalKeys.update` | Admin | `POST /v1/organizations/external_keys/{external_key_id}` |
| `externalKeys.delete` | Admin | `DELETE /v1/organizations/external_keys/{external_key_id}` |
These permissions manage your organization's encryption key registrations. Of the three predefined roles, only `roles/claude.admin` includes them.
### Usage reports
| Permission | Roles | Routes authorized |
| --------------------- | ----- | --------------------------------------------- |
| `usageAnalytics.list` | Admin | `GET /v1/organizations/usage_report/messages` |
Of the three predefined roles, only `roles/claude.admin` includes `usageAnalytics.list`.
## See also
* [Claude Models on Google Cloud (Anthropic managed)](https://platform.claude.com/docs/en/build-with-claude/claude-models-on-google-cloud/anthropic-managed)
* [IAM roles](https://platform.claude.com/docs/en/build-with-claude/claude-models-on-google-cloud/anthropic-managed#iam-roles)
* [Monitoring and logging](https://platform.claude.com/docs/en/build-with-claude/claude-models-on-google-cloud/anthropic-managed#monitoring-and-logging)
api/errors Changed · +4 / -4 lines
api/migration-2026-10-21 New page · 1339 lines, new page
## Upgrade steps ## Breaking changes ### Messages API #### Document blocks in assistant messages return an error #### Citations in user messages return an error #### Sampling parameters are removed ### Admin API and Claude Enterprise Analytics API #### `workspace_id` on API keys ## SDK and CLI changes ### `MessageParam` is a union with one type for each role ### One-value enums are constants ### Client-side compaction is removed from the tool runner ### Text Completions is removed ### `betas` is removed from the non-beta Models methods ### API keys are sent as `Authorization: Bearer` #### If a proxy or gateway reads `X-Api-Key` #### If you set or removed `X-Api-Key` on a request ### A client holds one credential ### Changes in one SDK or the CLI ### The license is Apache 2.0
A whole new page. There's nothing to diff it against, so here is what it says.
---
title: Migrating to API version 2026-10-21
url: https://platform.claude.com/docs/en/api/migration-2026-10-21
description: "Upgrade a Claude API integration from API version 2023-06-01 to 2026-10-21: the SDK version to install and the code changes to make."
---
This guide lists the code changes for moving from API version `2023-06-01` to `2026-10-21`. The [upgrade steps](https://platform.claude.com/docs/en/api/migration-2026-10-21#migration-checklist) say what to do, in order.
## Upgrade steps
<Steps>
<Step title="Switch to 2026-10-21">
If you use an SDK, your requests use the API version that was current when your SDK's major version was released. The versions shown for your language are the first to use `2026-10-21`, so upgrade to them. If you call the API without an SDK, set the `anthropic-version` header to `2026-10-21`.
<Tabs>
<Tab title="cURL">
Set the `anthropic-version` header to `2026-10-21`:
```bash
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2026-10-21" \
-H "content-type: application/json" \
-d '{
"model": "claude-opus-5-5",
"max_tokens": 1024,
"messages": [{"role": "user", "content": "Hello, Claude"}]
}'
```
</Tab>
<Tab title="CLI">
Upgrade the `ant` CLI to version 2.0.0. The Homebrew command and the release downloads stay the same.
Go requires the path of a module at major version 2 or later to end in that version, so the CLI's module path is now `github.com/anthropics/anthropic-cli/v2`. If you install with `go install`, add `/v2` to the path:
```bash
# Before
go install 'github.com/anthropics/anthropic-cli/cmd/ant@latest'
# After
go install 'github.com/anthropics/anthropic-cli/v2/cmd/ant@latest'
```
The old path keeps installing the latest v1 release, with no error or warning.
</Tab>
<Tab title="Python">
Upgrade the `anthropic` package to version 2.0.0.
</Tab>
<Tab title="TypeScript">
Upgrade the `@anthropic-ai/sdk` package to version 1.0.0.
v1 of `@anthropic-ai/bedrock-sdk`, `@anthropic-ai/vertex-sdk`, `@anthropic-ai/foundry-sdk`, `@anthropic-ai/aws-sdk`, and `@anthropic-ai/google-cloud-sdk` needs v1 of `@anthropic-ai/sdk`, and their earlier versions need a version below 1. If you use one of them, move it to v1 in the same upgrade. Otherwise your package manager installs a second, older copy of `@anthropic-ai/sdk` for it.
</Tab>
<Tab title="C#">
Upgrade the `Anthropic` package to version 13.0.0.
</Tab>
<Tab title="Go">
Upgrade to version 2.0.0 of the Go SDK, whose module path is `github.com/anthropics/anthropic-sdk-go/v2`. A new major version of a Go module has a new import path, so change each import of `github.com/anthropics/anthropic-sdk-go`, and of its packages such as `github.com/anthropics/anthropic-sdk-go/option`, to start with `github.com/anthropics/anthropic-sdk-go/v2`. Then run `go get github.com/anthropics/anthropic-sdk-go/v2`.
</Tab>
<Tab title="Java">
Upgrade the `com.anthropic:anthropic-java` artifact to version 3.0.0.
</Tab>
<Tab title="PHP">
Run `composer require "anthropic-ai/sdk"` to upgrade the package to version 1.0.0. `composer update` alone stays within your current version constraint.
</Tab>
<Tab title="Ruby">
Upgrade the `anthropic` gem to version 2.0.0.
</Tab>
</Tabs>
<Warning>
On Amazon Bedrock, `2026-10-21` is available only for Claude 4.7 and later models. If you call an older model on Bedrock, listed in [Claude on Amazon Bedrock (Opus 4.6 and earlier)](https://platform.claude.com/docs/en/build-with-claude/claude-on-amazon-bedrock-legacy), stay on the SDK version you use today, or, if you set the API version yourself, keep sending the version you send today. To move those calls to `2026-10-21`, first switch them to a Claude 4.7 or later model.
</Warning>
Release the upgrade together with your fixes from the next step.
</Step>
<Step title="Update your code for the breaking changes">
Go through the [breaking changes](https://platform.claude.com/docs/en/api/migration-2026-10-21#breaking-changes), and update your code for each one that affects you. Also make the [code changes that the new SDK or CLI version needs](https://platform.claude.com/docs/en/api/migration-2026-10-21#sdk-changes).
</Step>
<Step title="Test against 2026-10-21">
Test your integration against `2026-10-21` before you release.
</Step>
</Steps>
## Breaking changes
### Messages API
These changes apply to requests to the Messages API (`POST /v1/messages`), to [token counting](https://platform.claude.com/docs/en/build-with-claude/token-counting), and to each request in a [Message Batch](https://platform.claude.com/docs/en/build-with-claude/batch-processing) created with `2026-10-21`.
#### Document blocks in assistant messages return an error
Affects you if you send `document` blocks directly in `assistant` messages.
In `2026-10-21`, a request that places a `document` block directly in an `assistant` message returns a 400 error. Send documents in `user` messages instead. A document nested inside another block, such as a web fetch tool result that Claude returned, is still accepted.
#### Citations in user messages return an error
Affects you if you send `citations` on `text` blocks in `user` messages, including inside `search_result` blocks.
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. Remove `citations` from those blocks. Citations on `text` blocks in `assistant` messages, such as Claude's earlier replies that you send back, are still accepted, and so is the `"citations": {"enabled": true}` setting on documents and search results.
#### Sampling parameters are removed
Affects you if you send `temperature`, `top_p`, or `top_k` in Messages requests or Message Batch requests.
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.
Remove the three parameters from your requests.
As of the latest major versions, the SDK and the CLI no longer have the three parameters.
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. 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`.
### Admin API and Claude Enterprise Analytics API
Affects you if your code reads the Admin API or Claude Enterprise Analytics API response fields in the following tables.
In `2026-10-21`, responses from the Admin API and the [Claude Enterprise Analytics API](https://platform.claude.com/docs/en/manage-claude/analytics-api) no longer include the old names of renamed fields. Use the new names instead.
Admin API:
| Endpoints | Old name | New name |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| [RBAC groups](https://platform.claude.com/docs/en/api/beta/organization/rbac_groups/list): create, list, retrieve, and update | `roles` | `role_ids` |
| [RBAC group members](https://platform.claude.com/docs/en/api/beta/organization/rbac_groups/members/list): list and add, and the response to [removing a member](https://platform.claude.com/docs/en/api/beta/organization/rbac_groups/members/remove) | `group_id` | `rbac_group_id` |
| [RBAC roles](https://platform.claude.com/docs/en/api/beta/organization/rbac_roles/list): list and retrieve | `name` | `display_name` |
| [Organization](https://platform.claude.com/docs/en/api/organization/rate_limits/list) and [workspace](https://platform.claude.com/docs/en/api/organization/workspaces/rate_limits/list) rate limits: list, and the response to setting a workspace's rate limits | `group_type` | `group.type` |
| [API keys](https://platform.claude.com/docs/en/api/organization/api_keys/list): list, retrieve, and update | `workspace_id` | `scope` (different values; see [`workspace_id` on API keys](https://platform.claude.com/docs/en/api/migration-2026-10-21#api-key-workspace-id)) |
Claude Enterprise Analytics API:
| Endpoints | Old name | New name |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | --------------------- |
| Per-user [usage](https://platform.claude.com/docs/en/api/beta/organization/analytics/user_usage_report/list) and [cost](https://platform.claude.com/docs/en/api/beta/organization/analytics/user_cost_report/list) reports | `actor.email` | `actor.email_address` |
| [Activity summaries](https://platform.claude.com/docs/en/api/beta/organization/analytics/summaries/list) | `summaries` | `data` |
The `group_type` query parameter on the rate-limit list endpoints and the `workspace_id` filter on the API key list endpoint are unchanged.
#### `workspace_id` on API keys
Affects you if your code reads `workspace_id` on API keys.
In `2023-06-01`, an API key's `workspace_id` is the ID of the workspace the key is bound to, or `null` for a key bound to the Default Workspace and for a key that isn't bound to one workspace (an all-workspaces key).
In `2026-10-21`, `workspace_id` is removed. Read `scope` instead: for a key bound to a workspace, including the Default Workspace, `scope.workspace_id` is that workspace's real ID, and an all-workspaces key has a `scope` of `{"type": "organization"}`, with no `workspace_id`.
If your code treated a `null` `workspace_id` as the Default Workspace, compare `scope.workspace_id` with your Default Workspace's ID instead. To find that ID, call [List Workspaces](https://platform.claude.com/docs/en/api/organization/workspaces/list) with `include_default=true` and take the workspace named `"Default"`.
## SDK and CLI changes
Earlier SDK and CLI versions sent `anthropic-version: 2023-06-01` with every request. The versions under [Switch to 2026-10-21](https://platform.claude.com/docs/en/api/migration-2026-10-21#upgrade) send `2026-10-21`, including their Amazon Bedrock and Google Cloud clients. The changes in [Breaking changes](https://platform.claude.com/docs/en/api/migration-2026-10-21#breaking-changes) apply to them too: the removed parameters and the old field names are also gone from the SDK's types and from the CLI's flags and output.
### `MessageParam` is a union with one type for each role
In earlier versions, `MessageParam` was one type for all roles. Each role now has a type of its own: `UserMessageParam`, `AssistantMessageParam`, and `SystemMessageParam`. `BetaMessageParam` is split the same way, into `BetaUserMessageParam`, `BetaAssistantMessageParam`, and `BetaSystemMessageParam`. The requests that the SDK sends have the same fields and values as before.
<Tabs exclude="shell">
<Tab title="Python">
A message written as a dict literal, such as `{"role": "user", "content": "Hello"}`, needs no change.
In v1, `anthropic.types.MessageParam` was one `TypedDict`. In v2 it is a union of the three types, and `anthropic.types.beta.BetaMessageParam` is a union of its three. Both names still work in annotations, such as `list[MessageParam]`.
Calling either name now raises a `TypeError`, and a type checker flags it. Write the message as a dict:
```python
# Before
message = MessageParam(role="user", content="Hello")
# After
message: MessageParam = {"role": "user", "content": "Hello"}
```
Subclassing either name also raises a `TypeError`. Subclass the type for the role, such as `UserMessageParam`.
The remaining changes affect type checking only. A dict whose `role` is a variable that can hold more than one role matches no type in the union, so build the dict for one role at a time:
```python
# Before
def to_message(role: Literal["user", "assistant"], text: str) -> MessageParam:
return {"role": role, "content": text}
# After
def to_message(role: Literal["user", "assistant"], text: str) -> MessageParam:
if role == "user":
return {"role": "user", "content": text}
return {"role": "assistant", "content": text}
```
Two more apply to `BetaMessageParam` only:
* `clear_at` and `output_config` are keys of `BetaSystemMessageParam`, so a user or assistant message can't have them.
* `content` is optional in `BetaSystemMessageParam`, so pyright reports `message["content"]`. Read it with `message.get("content")`, or check first that `message["role"]` is not `"system"`.
</Tab>
<Tab title="TypeScript">
`MessageParam` was one interface. It is now `UserMessageParam | AssistantMessageParam | SystemMessageParam`, and `BetaMessageParam` is the same union of its three types. Only the types changed. A message literal that names its role, such as `{ role: "user", content: "Hello, Claude" }`, type-checks as it did, so most code needs no change.
The system type differs from the other two. Its `content` is a string or text blocks, plus `tool_addition` and `tool_removal` blocks in `beta`, so an image block there no longer compiles. In `beta`, only it has `clear_at` and `output_config`, and its `content` is optional.
Code that handles a message of any role has to check `role` before it replaces or adds content blocks, and before it reads `clear_at` or `output_config`:
```typescript
// Before
const copy: Anthropic.MessageParam = { ...message, content: blocks };
// After
const copy: Anthropic.MessageParam =
message.role === "system" ? message : { ...message, content: blocks };
```
The `content` of a `BetaMessageParam` can be `undefined`:
```typescript
// Before
const types =
typeof message.content === "string" ? [] : message.content.map((block) => block.type);
// After
const types = Array.isArray(message.content) ? message.content.map((block) => block.type) : [];
```
The type `BetaMessageParam["content"]` includes `undefined` too. For the content of a user or assistant message, use `BetaMessageContentParam`.
An interface can't extend a union, and a class can't implement one. Use a type alias, or name the type of one role instead.
```typescript
// Before
interface StoredMessage extends Anthropic.MessageParam {
id: string;
}
// After
type StoredMessage = Anthropic.MessageParam & { id: string };
```
</Tab>
<Tab title="C#">
In v12, `MessageParam` and `BetaMessageParam` were classes whose `Role` and `Content` you set. In v13 each is a union of the three classes for its roles, and the `Role` enums in `Anthropic.Models.Messages` and `Anthropic.Models.Beta.Messages` are gone.
When you build a message, name the class for its role and delete `Role`. Each class converts to the union implicitly:
```csharp
// Before
Messages = [new() { Role = Role.User, Content = "Hello, Claude" }],
// After
Messages = [new UserMessageParam { Content = "Hello, Claude" }],
```
`new UserMessageParam("Hello, Claude")` works too.
The classes that hold `Content` change as well:
* `MessageParamContent` is now `MessageContentParam`, and `BetaMessageParamContent` is now `BetaMessageContentParam`.
* A system message has a content class of its own. A `SystemMessageParamContent` holds a string or a list of `TextBlockParam`, and a `BetaSystemMessageParamContent` holds a string or a list of `SystemMessageContentBlock`. A `List<ContentBlockParam>` or a `List<BetaContentBlockParam>` no longer converts to it.
* `ClearAt` and `OutputConfig` are on `BetaSystemMessageParam` only.
When you read a message, the union still has `Role` and `Content`, but you can't set them, so a `with` expression goes on the class for the role. `Role` now holds a `MessageParamRole` or a `BetaMessageParamRole`. `BetaMessageParam.Content` can be `null`, because `Content` is optional on `BetaSystemMessageParam`.
```csharp
// Before
if (message.Role.Value() == Role.Assistant) { }
// After
if (message.Role.Value() == MessageParamRole.Assistant) { }
```
`TryPickUser`, `TryPickAssistant`, `TryPickSystem`, `Switch`, and `Match` give you the class for the role.
</Tab>
<Tab title="Go">
In v1, `MessageParam` was one struct with a `Role` and a `Content` field. In v2 it is a union: `OfUser` holds a `*UserMessageParam`, `OfAssistant` an `*AssistantMessageParam`, and `OfSystem` a `*SystemMessageParam`. `BetaMessageParam` changes in the same way. The SDK sends the same JSON as before, apart from the order of the keys in a beta system message.
`NewUserMessage`, `NewAssistantMessage`, `NewBetaUserMessage`, and the `ToParam` methods of `Message` and `BetaMessage` work as before, so code that builds its messages with them needs no change.
A struct literal names the type for its role. Leave `Role` out, because each type marshals its own:
```go
// Before
anthropic.MessageParam{
Role: anthropic.MessageParamRoleAssistant,
Content: blocks,
}
// After
anthropic.MessageParam{OfAssistant: &anthropic.AssistantMessageParam{
Content: blocks,
}}
Cut at 300 lines. The page has the rest.