Skip to main content
The general pattern for any Python script that calls external APIs. No framework required.

​
Run under the proxy

The script reads env vars normally; authsome injects the real values at the proxy layer. 
authsome login openai
authsome login github
authsome run -- python my_script.py
In the script: 
import os
import httpx

# These look like real values to the script but are placeholders.
# Authsome's proxy substitutes the real secret on outbound requests.
key = os.environ["OPENAI_API_KEY"]
gh = os.environ["GITHUB_ACCESS_TOKEN"]

r = httpx.get("https://api.openai.com/v1/models", headers={"Authorization": f"Bearer {key}"})
print(r.json())

r = httpx.get("https://api.github.com/user", headers={"Authorization": f"Bearer {gh}"})
print(r.json())
No authsome import in the script. The proxy does the work. This is the recommended path for almost every script.

​
Export when the proxy is not enough

When you need to pass tokens explicitly (TLS-pinned SDKs, non-HTTP protocols, or per-call connection selection): 
eval "$(authsome export openai --format env)"
eval "$(authsome export github --connection work --format env)"
python my_script.py
See Python library for the daemon HTTP API when building custom orchestration.

​
When the proxy isn’t enough

The export path is the right tool when:
  • The SDK pins TLS certificates and refuses to trust the mitmproxy CA.
  • You’re using non-HTTP protocols (WebSockets, gRPC over HTTP/2, raw TCP) that the proxy can’t intercept.
  • You need to pick a different connection per call within the same process.
  • You’re embedding authsome inside a larger orchestrator with its own subprocess management.
Otherwise, the proxy is simpler.

​
Multi-account

authsome export github --connection personal --format env
authsome export github --connection work --format env
See Multiple connections per provider.

​
What’s next

Python library

Every part of the library surface.

Run agents with the proxy

The proxy injection model.