[fzowl]

What

Adds voyageai.util.get_batch_base_url(api_key) — the base-URL seam for the batch and files APIs, which are served from a dedicated batch. subdomain:

• https://api.voyageai.com/v1 → https://batch.api.voyageai.com/v1

It derives the batch host from get_default_base_url(), preserving the /v1 path convention. The MongoDB host (al- keys → ai.mongodb.com/v1) is left untouched, since the batch. subdomain only applies to the Voyage AI host.

Why

Batch/files calls need to target batch.api.voyageai.com while every other endpoint (embeddings, rerank, multimodal embeddings, contextualized embeddings) keeps using api.voyageai.com. This is not a breaking change — get_default_base_url() is unchanged, so all existing endpoints are unaffected.

Note for the requester

The SDK does not currently implement batch or files endpoints — the only API resources today are embeddings, multimodalembeddings, rerank, and contextualizedembeddings (see voyageai/api_resources/), all of which resolve their host purely via get_default_base_url() in voyageai/util.py and hit it through APIRequestor (base_url + url).

So there is no existing batch/files call site to repoint. This PR adds the exact seam to call from those endpoints once they land: when the batch/files APIResource/client methods are added, pass base_url=util.get_batch_base_url(api_key) (or wire it in _BaseClient.__init__ for those resources) instead of the default. That keeps host selection in one place, consistent with get_default_base_url().

If you'd instead prefer a client constructor arg or an env override, say so and I'll adjust — this was the minimal change that matches the existing code shape.

Tests

Added to tests/test_unit.py:

• test_get_batch_base_url_voyage → https://batch.api.voyageai.com/v1
• test_get_batch_base_url_mongodb → unchanged https://ai.mongodb.com/v1
• test_get_batch_base_url_leaves_default_unchanged → default still https://api.voyageai.com/v1

pytest tests/test_unit.py -k base_url → 5 passed. Full tests/test_unit.py → 128 passed, 12 skipped; the 3 failures are pre-existing and unrelated (missing ffmpeg module in the local env, in TestVideoUtilsErrorPaths).

[fzowl]

Thanks — reviewed the diff. It's small, additive, non-breaking, and the string logic is correct: pa- keys → https://batch.api.voyageai.com/v1, al- (MongoDB) and any other host left untouched, /v1 preserved, default host unchanged. Tests cover the three relevant cases. A few things to resolve before merge:

1. Unverified endpoint constant. The whole value of this PR rests on batch.api.voyageai.com being the real batch/files host. That's an infra fact the SDK shouldn't guess at — please confirm it against the actual Voyage batch service before merging, since a future author wiring up batch endpoints will trust this string blindly.

2. Ignores custom base_url. get_batch_base_url(api_key) derives purely from the API key via get_default_base_url, so it discards any custom base_url a client was constructed with (_base.py:78). A user pointing the client at a proxy/staging host would have batch/files calls silently bypass that override and hit prod batch.api.voyageai.com. get_default_base_url has the same key-only shape, but it's at least always overridable at the APIRequestor/client layer; a bare module function is not. Worth deciding now whether batch host selection should compose with the client's configured base_url (e.g. derive from the effective base_url, or subdomain-prefix whatever host is in play) rather than hardcoding the voyageai.com literal.

3. Dead code until batch lands. As the description notes, nothing calls this yet — no batch/files resource exists. Adding a public-ish util helper + an unverified endpoint that won't be exercised carries a small rot/drift risk. Reasonable to land the seam alongside the first batch resource instead, so it's actually covered by an integration path. Maintainer's call, but flagging it.

None of these are correctness bugs in the code as written; (1) and (2) are the ones I'd want settled before this ships.

[fzoll]

I believe there is a misunderstanding here. The following is about the batch inference: https://docs.voyageai.com/docs/batch-inference. So, i guess, at the moment none of the batch inference is implemented, therefore it should be a completely new implementation, the batch is not implemented in the SDKs. Please confirm!