#2408·instructor

feat(bedrock): support Amazon Bedrock API key (bearer token) authentication

Author: Winne004Created Jul 3, 2026Updated Aug 13, 2026

Is your feature request related to a problem? Please describe.

The Bedrock provider currently offers no way to authenticate with an Amazon Bedrock API key (bearer token). Bedrock API keys let you call the service with a bearer token instead of SigV4-signed AWS credentials, and come in two flavors:

  • Short-term – lasts up to 12 hours (or the duration of your session, whichever is shorter), inherits permissions from the IAM principal that generated it. Recommended for production.
  • Long-term – lasts until a configured expiration date, backed by an auto-created IAM user. Recommended only for exploration.

Today, _build_bedrock in instructor/v2/auto_client.py explicitly ignores the api_key argument and only wires up classic credential parameters:

https://github.com/567-labs/instructor/blob/main/instructor/v2/auto_client.py

python
def _build_bedrock(
    *,
    provider: str,
    model_name: str,
    async_client: bool,
    mode: Mode | None,
    api_key: str | None,  # noqa: ARG001   <-- silently ignored
    kwargs: dict[str, Any],
    ...
) -> InstructorType:
    ...
    for key in [
        "aws_access_key_id",
        "aws_secret_access_key",
        "aws_session_token",
    ]:
        ...

So this silently falls back to the default credential chain instead of using the key:

python
client = instructor.from_provider(
    "bedrock/anthropic.claude-3-5-sonnet-20240620-v1:0",
    api_key="bedrock-api-key-...",  # ignored, no warning
)

This hurts ergonomics for people trying out instructor with Bedrock: every other major provider (openai/..., anthropic/..., etc.) works with a single api_key, while Bedrock forces users to set up the full AWS credential chain even though the service itself now supports simple bearer-token auth.

Describe the solution you'd like

Support Bedrock API keys in the Bedrock provider path:

  1. In _build_bedrock, when api_key is passed (or AWS_BEARER_TOKEN_BEDROCK is set in the environment), configure the boto3 client to use bearer-token auth instead of SigV4 credentials. botocore natively supports this since boto3 1.39.0 via the AWS_BEARER_TOKEN_BEDROCK environment variable, so a minimal implementation could be:

    python
    if api_key:
        os.environ["AWS_BEARER_TOKEN_BEDROCK"] = api_key

    (or, more hygienically, by injecting the token into the botocore session/auth config rather than mutating os.environ).

  2. Document the option in the Bedrock integration docs, including the AWS_BEARER_TOKEN_BEDROCK environment variable, so users know both paths exist.

  3. If bearer auth can't be honored (e.g. boto3 too old), raise or warn instead of silently ignoring api_key.

Describe alternatives you've considered

  • Setting AWS_BEARER_TOKEN_BEDROCK manually before creating the client — this works because botocore picks it up, but it is undocumented in instructor and doesn't help users who reach for the api_key parameter that every other provider accepts.
  • Building a boto3 client myself and using instructor.from_bedrock(client) — works, but defeats the purpose of the from_provider one-liner.
  • At minimum, a warning when api_key is passed to from_provider("bedrock/...") would prevent silent misconfiguration.

Additional context

Happy to submit a PR for this if the approach above sounds reasonable.