Files
agentrhq__authsome/docs/site/integrations/agents/langchain.mdx
Priyansh Khodiyar 71b89fd036 docs(site): adopt skill-driven CLI conventions across the docs
The skill rewrite (PR #284) and README update standardized on
"authsome <command>" (assumes "uv tool install authsome") and on
agent-driven login flows. The docs site still spoke "uvx authsome"
everywhere and didn't surface the auth-error decision tree the
skill teaches. This brings the docs in line.

Four kinds of change in one PR.

1. CLI prefix sweep ("uvx authsome" to "authsome").

Mechanical find/replace across docs/site/ excluding installation.mdx.
812 occurrences updated. installation.mdx keeps the literal "uvx"
references because they explain the one-off run path.

2. installation.mdx rewrite.

- "uv (recommended)" tab leads, with "uv tool install authsome".
- pip second.
- uvx demoted to "one-off, no install" with @latest pattern shown.
- From source unchanged.
- A Note at the top declares: every command in the docs is the
  installed form; uvx users prefix with "uvx authsome@latest".
- All subsequent code blocks updated to bare "authsome".

3. New troubleshooting/auth-errors.mdx page.

Captures the decision tree the skill teaches: 401 -> revoke +
re-login; 403 -> "authsome login --scopes" (not re-registering);
wrong client creds -> "authsome remove" then re-login. Registered
in docs.json under Troubleshooting.

4. quickstart.mdx pivoted to two paths + help reflex.

Path 1: agent-driven. Install the skill, ask the agent to do a
task that needs an external service. The agent runs login itself.
Path 2: CLI-driven. The existing manual walkthrough, preserved.
Adds a Tip about reading "authsome --help" and "authsome <cmd>
--help" before guessing flags.

5. Agent-mode note on the four skill-based integration pages.

claude-code, codex, cursor, opencode each get a one-paragraph Note
clarifying that the agent runs login, opens the browser on the
user's machine for OAuth, and that users should not paste keys
into prompts or pre-run login commands. The four SDK-style
integration pages (langchain, llamaindex, openai-agents-sdk,
anthropic-sdk) are unchanged because their pattern is
developer-driven, not agent-driven.

Verified clean: no "uvx authsome" outside installation.mdx,
docs.json valid, no em-dashes introduced.
2026-05-19 16:12:42 +05:30

80 lines
2.9 KiB
Plaintext

---
title: "LangChain"
sidebarTitle: "LangChain"
description: "Use authsome with LangChain. Pull fresh tokens at agent construction or run the whole chain under the proxy."
icon: "link"
keywords: ["langchain authsome", "langchain credentials", "langchain oauth", "langchain api keys"]
---
[LangChain](https://www.langchain.com) reads provider credentials from environment variables or constructor arguments. The recommended setup: run the chain under authsome's proxy and let LangChain's SDKs read the placeholder env vars unchanged.
## Run the whole chain under the proxy
```bash
authsome login openai
authsome login github
authsome run -- python my_chain.py
```
LangChain SDKs read placeholder env vars (`OPENAI_API_KEY=authsome-proxy-managed`) and initialize. The proxy substitutes the real key for outbound HTTPS to `api.openai.com`, `api.github.com`, and other matched hosts. No code changes to your chain.
## Tools that call out to providers
Many LangChain tools (`GitHubToolkit`, `SerpAPIWrapper`, `BraveSearch`, etc.) read their secret from an env var. With the proxy already wrapping the process, the existing wrappers just work:
```python
from langchain_community.utilities import SerpAPIWrapper
# reads SERPAPI_API_KEY from env, which is the proxy placeholder
search = SerpAPIWrapper()
```
For tools that authsome doesn't bundle, add a [custom provider](/guides/custom-providers) so the proxy can match by host.
## Embedding the library
If you're building a larger orchestrator around LangChain and need to pass tokens explicitly (different connection per call, or TLS-pinned SDKs that bypass the proxy), drop down to the library:
```python
from authsome.server.dependencies import create_auth_service
from langchain_openai import ChatOpenAI
from langchain_community.tools.github.tool import GitHubAction
auth = create_auth_service()
llm = ChatOpenAI(
api_key=auth.get_access_token("openai"),
model="gpt-4o-mini",
)
github = GitHubAction(
github_access_token=auth.get_access_token("github"),
)
```
Refresh is transparent. Construct the clients once per request rather than caching them across long-running processes if your tokens have short TTLs.
## Async clients
`AsyncChatOpenAI` and other async wrappers work identically. Authsome's auth layer is synchronous; if you do use the library, call `get_access_token` once at client construction and pass the value in.
## Multi-account workflows
```python
work = auth.get_access_token("github", connection="work")
personal = auth.get_access_token("github", connection="personal")
```
See [Multiple connections per provider](/guides/multiple-connections).
## What's next
<Columns cols={2}>
<Card title="Python library" icon="code" href="/reference/python-library">
The full library surface.
</Card>
<Card title="OpenAI integration" icon="key" href="/integrations/api-key/openai">
Set up the OpenAI key LangChain will use.
</Card>
</Columns>