Anthropic's Files API (currently beta on the first-party API) lets applications upload a document once, get back a file ID, and reference that ID across many requests. Amazon Bedrock does not support it. Bedrock also does not support URL input sources for images and documents — you cannot point Claude at a link and have the platform fetch it. The practical consequence is the same for both gaps: on Bedrock, document content must be embedded inline in the request body, typically base64-encoded, on every call that needs it.
This is less of a problem than it first sounds, but it changes three design decisions: where files live, how big requests get, and how you avoid paying to resend the same document repeatedly.
Pattern 1: Inline documents in the request body
Claude on Bedrock accepts documents and images as typed content blocks. Images use a base64 source block with a media type; PDFs are supported through both the current Messages surface and the legacy InvokeModel and Converse APIs. The straightforward pattern is: read the file, base64-encode it, and include it as a content block alongside your instruction text.
import base64
from anthropic import AnthropicBedrockMantle
client = AnthropicBedrockMantle(aws_region="us-east-1")
pdf_b64 = base64.standard_b64encode(open("contract.pdf", "rb").read()).decode()
response = client.messages.create(
model="anthropic.claude-sonnet-5",
max_tokens=2048,
messages=[{"role": "user", "content": [
{"type": "document",
"source": {"type": "base64", "media_type": "application/pdf",
"data": pdf_b64}},
{"type": "text", "text": "Summarize the termination clauses."},
]}],
)
print(response.content[0].text)One legacy-surface nuance worth knowing: on the Converse API, full visual PDF analysis requires citations to be enabled — without citations you get basic text extraction only. InvokeModel gives you full control. If PDF understanding quality matters and you are on the legacy surface, test both paths.
Pattern 2: Stage files in S3, inline at call time
"No Files API" does not mean "no file store." The idiomatic Bedrock architecture keeps documents in Amazon S3 — with your existing encryption, access controls, and lifecycle rules — and has the application fetch and inline the bytes at request time. S3 becomes your system of record; the request body is just transport. This keeps large corpora out of your application servers, lets multiple services share the same documents, and means your data-governance story for documents is the standard S3 one your security team already reviews.
Mind the limits
| Limit | Value on Bedrock |
|---|---|
| Request payload size | 20 MB |
| Images or PDF pages per request | Up to 600 on 1M-context models (100 on 200K-context models) |
| Context window | 1M tokens on Claude Fable 5, Opus 4.8/4.7/4.6, Sonnet 4.6; 200K on Sonnet 4.5 and older |
Base64 encoding inflates file size by roughly a third, so budget against the 20 MB payload cap accordingly. Everything in the request — documents, images, system prompt, tool definitions — counts toward the model's context window. For documents too large to inline, fall back to extraction-and-chunking: pull the text out yourself, split it, and send the relevant sections rather than the whole binary.
Don't resend what you can cache
The cost concern with inlining — "I'm paying input tokens for the same 80-page PDF on every request" — has a direct answer: prompt caching, which Bedrock supports with 5-minute and 1-hour durations. Place the document early in the prompt, mark a cache_control breakpoint after it, and repeated requests within the cache window read the document at the cache-read rate (0.1x the base input price) instead of full price. Note that Bedrock requires explicit breakpoints — the automatic caching mode available on the first-party API is not supported there. See the Bedrock prompt caching guide for the mechanics.
Where to go next
Pair this with prompt caching on Bedrock to control cost, check the feature availability matrix for what else differs from the first-party API, and see the document processing use-case guide for end-to-end patterns.