Custom headers not forwarded to Azure OpenAI via Weaviate Python SDK

Other Questions OpenAI
1

I’m working with the Weaviate Python SDK and trying to set up a collection that connects to Azure OpenAI using the text2vec-azure-openai module. The basic setup works fine with the X-Azure-Api-Key header and embeddings are generated successfully.

However, I need to pass some custom headers directly to the Azure OpenAI API calls, but they don’t seem to be forwarded. Here’s my current configuration:

my_weaviate_client = WeaviateClient(
    connection_params=ConnectionParams(
        http=ProtocolParams(host=server_host, port=server_port, secure=False),
        grpc=ProtocolParams(host=server_host, port=grpc_server_port, secure=False),
    ),
    additional_headers={
        "X-Azure-Api-Key": my_api_key,
        "my_custom_header": "header_value",
    },
    skip_init_checks=True,
)
my_weaviate_client.connect()

The custom headers in the additional_headers dictionary aren’t being passed through to Azure OpenAI. Is there a different way to include custom headers that will be sent with the OpenAI requests, or is this functionality not supported?

2

Been fighting this same issue for months. Weaviate and Azure OpenAI are completely isolated in the SDK - makes sense architecturally but kills custom implementations. Here’s what actually works: modify the collection config when you create it, not at the client level. In your collection schema, the text2vec-azure-openai module takes a headers parameter in the config block. This gets passed straight to Azure OpenAI calls. Problem is these headers are locked once the collection exists. Need dynamic headers that change per request? You’re screwed. I ended up making multiple collections with different header configs for different use cases. Not pretty, but it works. Alternative is intercepting at the HTTP layer with a reverse proxy between Weaviate and Azure OpenAI. More complex setup but gives you total control over headers and routing.

3

Had this exact problem last year building a multi-tenant app. Weaviate treats client headers and vectorizer headers as totally separate things. Your additional_headers only talk to the Weaviate server - they never reach Azure OpenAI. I fixed it by setting headers at the collection level in the vectorizer config. When you define your collection schema, put the headers in the text2vec-azure-openai moduleConfig section. Those headers get sent straight to Azure OpenAI with each embedding request. Catch is you can’t change these headers once the collection exists - you’d have to recreate it. For runtime flexibility, I ended up preprocessing outside Weaviate. I call Azure OpenAI directly with custom headers, then insert the vectors myself. More work but you get full control over the API calls.

4

azure integrations r a pain sometimes. yeah, weaviate client headers don’t get passed through to openai - found that out the hard way too. set up a middleware proxy in front of azure openai instead. much easier than dealing with collection configs.

5

This headache is exactly why I skip SDK wrestling and go straight to automation workflows.

Weaviate’s SDK won’t forward custom headers to Azure OpenAI - it sees them as separate services. Sure, you could try the moduleConfig workaround others mentioned, but that gets ugly when you need dynamic headers or complex logic.

I’ve solved similar integration problems by building automation flows that control the entire API chain. Catch the data before Weaviate, hit Azure OpenAI with your custom headers, then feed the embeddings back.

You get logging, error handling, header manipulation, and fallback logic if Azure goes down. Easy to swap embedding models or add preprocessing without touching your main code.

Way cleaner than forcing the SDK to do something it wasn’t built for. Set it up once and never worry about header forwarding again.

6

The additional_headers parameter in WeaviateClient only affects requests to the Weaviate server - not downstream services like Azure OpenAI. That’s intentional since Weaviate sits in the middle. For Azure OpenAI, you’ll need to add custom headers through the vectorizer config when you create your collection schema. Check the moduleConfig section for text2vec-azure-openai - that’s where you can specify HTTP headers to forward to Azure OpenAI. If you need more header control, consider generating embeddings outside Weaviate and inserting vectors directly. You’ll get full control over API calls but it’s more manual work.

7

Everyone’s suggesting workarounds but missing the point.

This isn’t just about custom headers - you’re locked into whatever Weaviate supports. What happens when you need request logging? Rate limiting? Retry logic? Different model fallbacks?

I solve this with an automation layer between your app and these services. Don’t fight SDK limitations - create a workflow that processes your data first.

Grab your content, call Azure OpenAI with whatever headers you need, handle the response, then push clean vectors to Weaviate. You get full control over Azure calls plus proper error handling and monitoring.

When Azure changes their API or you need different headers per tenant, just update the workflow. No schema rebuilds, no collection juggling, no proxy servers.

Bonus: easily add preprocessing, content filtering, or switch embedding models without touching your main app.

8

totally get where ur coming from! yeah, the weaviate headers ain’t sent to openai. u should try adding custom headers in the schema setup instead. if u check the vectorizer config, there should be a place for it. hope that helps!