# Bedrock Claude Structured Outputs: What's Expanded and What to Check AWS announces broader schema-constrained output support, while conflicting endpoint documentation makes integration checks especially important. By Paras Madan | 2026-10-20 AWS announced an expansion of structured outputs for Claude on Amazon Bedrock on October 19. The announcement covers structured JSON and strict tool inputs across Claude models and both runtime and Mantle endpoints where models are available. Current documentation still contradicts parts of that coverage, so availability needs checking. Structured outputs constrain a model's response to a supplied schema. For applications that extract records or call tools, that can reduce failures caused by malformed output. The important distinction is that a correctly shaped response can still contain an incorrect answer. ## What changed from Bedrock's earlier launch? Bedrock already had structured outputs. AWS's [February 4 announcement](https://aws.amazon.com/about-aws/whats-new/2026/02/structured-outputs-available-amazon-bedrock/) covered Claude 4.5 and selected open-weight models through runtime APIs. The [October 19 announcement](https://aws.amazon.com/blogs/machine-learning/structured-outputs-for-anthropic-claude-models-on-amazon-bedrock/) describes broader Claude coverage, including the `bedrock-runtime` and `bedrock-mantle` endpoints. It should be understood as an announced expansion of an existing capability, rather than Bedrock's first support for schema-constrained generation. That matters for teams using more than one Claude model or API surface. A shared output contract can make it easier to change the model behind a workflow without rewriting every downstream parser. The contract still needs to be checked against the exact endpoint and model combination an application uses. ## The endpoint documentation is inconsistent As checked on October 20, the [Bedrock structured-output documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/structured-output.html) still says the Mantle Messages endpoint rejects `output_config.format` with a 400 error. It directs Claude users to Converse or InvokeModel on `bedrock-runtime` instead. The announcement and documentation also differ on unsupported schema keywords. The blog describes cases where keywords may be accepted without enforcement; the documentation says unsupported schema features are rejected. Neither discrepancy has been resolved by an authenticated API test for this article. **Do not treat the announced coverage as a verified guarantee for every endpoint, model and schema.** The mismatch could reflect documentation or rollout timing, but the available sources do not establish which explanation applies. For an existing integration, a small test with the exact production schema is more useful than changing endpoints on the strength of a broad availability statement. Keep the current working path until the intended replacement passes the same checks. ## Structured JSON and strict tool inputs solve different problems A structured JSON response gives the application a predictable output shape. Strict tool use constrains the name and inputs of a model-generated tool call. The first helps a consumer parse a result; the second helps a tool receive inputs in the expected format. Consider an agent preparing a support-ticket update. A schema can require a ticket identifier, status and explanation. It cannot establish that the identifier belongs to the correct customer, that the proposed status is justified, or that the caller is allowed to change it. Those checks belong in the application and tool boundary. Removing them because the model produced valid JSON would confuse formatting reliability with authorization and business correctness. The October announcement also calls out refusals and responses cut short by token limits. Handle those outcomes explicitly rather than assuming every request yields a complete record that can be acted on immediately. ## Schema and latency limits to plan around The current documentation describes a JSON Schema subset, requires `additionalProperties: false`, and excludes recursive or external references and some numeric and string constraints. It also lists incompatibility with Anthropic citations and model-specific geographic-profile exceptions. These details are another reason to test the actual schema rather than a simplified example. An application may depend on a constraint that is enforced by its own validator but not by the model-facing schema support. AWS describes a compilation step for new schemas and a 24-hour, account-scoped grammar cache. The documentation says initial compilation can take minutes. Stable schemas can reuse the cache; continually generating different schemas can change the latency profile. No new surcharge or explicit zero-surcharge guarantee was verified for this expansion. Use the applicable [Bedrock pricing](https://aws.amazon.com/bedrock/pricing/) for the chosen model and service configuration rather than assuming the feature changes token rates. ## What developers should keep after adoption The reasonable goal is fewer formatting failures and less repair work. Track those failures separately from incorrect extracted values, refused requests, truncated responses and rejected tool actions. Otherwise, a cleaner JSON success rate can hide problems that still affect the completed task. Structured outputs make a useful boundary between a probabilistic model and deterministic software. The benefit is strongest when the software keeps ownership of the checks that a schema cannot express, and when the promised endpoint support has been verified for the application that will rely on it. I'm Paras. I work at the intersection of AI, engineering and distribution. I help AI teams explain API changes, integration constraints and technical product decisions in content that developers and founders can understand and share. [Book a 30-minute call](https://cal.com/paras-madan/30min).