Home → Help

The call works in curl but not from your application

curl and your application do not send the same request. The usual culprits are a proxy that only one of them honours, an environment variable overriding base_url, a key restricted to specific source addresses, or a client library appending a path you did not expect.

What you are seeing

Why it happens

OPENAI_BASE_URL, OPENAI_API_KEY and HTTPS_PROXY are read by many SDKs automatically. A stale value in the environment silently wins over the argument you passed in code.

Corporate proxies and TLS-inspecting middleboxes affect library HTTP stacks and curl differently. A certificate error from the SDK and a clean curl is the signature.

Keys can be restricted by source IP. Your laptop is allowed, the server is not, and the error is an authorisation failure that looks nothing like an IP problem.

Confirm it is this

Make the application print what it is actually about to use:

# Python
import os
print(os.getenv('OPENAI_BASE_URL'), os.getenv('HTTPS_PROXY'))
print(client.base_url)
# then reproduce curl from inside the same host
curl -s -o /dev/null -w '%{http_code}\n' \
  'YOUR_BASE_URL/models' -H 'Authorization: Bearer YOUR_KEY'

Run the curl from the same machine and the same shell as the app. Reproducing it from your laptop tests a different network path and proves nothing.

How to fix it

  1. Clear or align the environmentUnset stale OPENAI_* variables, or set them to the values you intend. Passing base_url explicitly in code does not always win.
  2. Check any IP restriction on the keyIf the key is limited to certain addresses, add the server's egress IP or use a key without a restriction for that deployment.
  3. Test from the failing hostReproduce with curl on the machine that fails, not the one that works. Half of these turn out to be network, not code.
APICLAN keys can be locked to specific source addresses with a per-key IP allowlist, which is worth setting for a key that runs from one fixed server — and worth checking first when a working key suddenly fails from a new host.

Related

Unexpected token '<' when calling an OpenAI-compatible API401 invalid API key — when the key looks right but still fails

Last checked 2026-10-01. Written from problems diagnosed on a live OpenAI-compatible gateway, not collected from other sites.