Getting 403 Forbidden on /runs/multipart despite valid key, correct workspace, and active billing

LangSmith Product Help Observability & Evals
1

Hi all,

I’m trying to enable LangSmith tracing for a small personal LangChain + Claude (Anthropic) project running locally on Windows (Python 3.12, langsmith 0.10.2, langchain-anthropic). Every trace ingestion attempt fails with a 403, even though I’ve verified the setup extensively. Details below.

Setup

  • Plan: Developer (free tier), payment card added, spend limit set to $5/month, usage limits configured (not left at defaults)
  • Workspace: single workspace (“Workspace 1”), confirmed via Settings > Workspaces
  • langsmith package version: 0.10.2 (confirmed this is current via PyPI)
  • Environment variables set via .env / python-dotenv: LANGSMITH_TRACING=true, LANGSMITH_API_KEY=…, LANGSMITH_PROJECT=research-agent

Error observed in application
When running my LangChain agent (using ChatAnthropic + llm.invoke()), I get repeated errors like:

Failed to multipart ingest runs: langsmith.utils.LangSmithError: Failed to POST https://api.smith.langchain.com/runs/multipart in LangSmith API. HTTPError(‘403 Client Error: Forbidden for url: https://api.smith.langchain.com/runs/multipart’, ‘{“error”:“Forbidden”}\n’)

The application itself continues to run fine (this is a non-blocking tracing failure), but no trace data is ever ingested.

Diagnostic steps already completed

  1. Verified the API key has no hidden/invisible characters (checked via repr() in Python) - clean
  2. Confirmed key format is correct (lsv2_pt_… for Personal keys)
  3. Tested authentication directly via the Python SDK (langsmith.Client().list_projects()) - fails with: HTTPError(‘403 Client Error: Forbidden for url: https://api.smith.langchain.com/sessions?limit=1&offset=0’, ‘{“detail”:“Forbidden”}’)
  4. Deleted and regenerated a completely fresh Personal API key - same 403
  5. Created and tested a Service API key instead of Personal - same 403
  6. Confirmed workspace scoping is correct (only one workspace exists, key is scoped to it)
  7. Added a payment card to the account specifically to rule out free-tier trace gating - still 403 afterward
  8. Confirmed langsmith package (0.10.2) is the current released version - not a stale-client issue
  9. Bypassed the Python SDK entirely and hit the API directly via curl:
    curl -H “x-api-key: [service key]” https://api.smith.langchain.com/api/v1/sessions?limit=1
    Result: still {“detail”:“Forbidden”}
  10. Checked the Tracing dashboard directly: the “research-agent” project does exist and is listed, but shows Trace Count: 0 and Error Rate: 0% for the last 7 days - meaning no trace has ever successfully landed, despite the project itself having been created at some point.

What this suggests
Since the project was created successfully at some point, but /sessions and /runs/multipart both consistently return 403 across multiple fresh keys (Personal and Service), across both the SDK and raw curl requests, this looks like either:

  • A permissions/scope issue specific to certain endpoints on this account, or
  • Some account-level flag/restriction that isn’t visible from the standard Settings pages (billing, workspace, API keys all look correctly configured)

Has anyone run into a 403 specifically on /runs/multipart (or /sessions) that persisted through all of the above? Any pointers on what else to check, or should I escalate this via direct support?

Happy to provide additional diagnostic output if useful. Thanks in advance.

2

Hi @kevin-seeto

If I’m looking at the correct org it looks like you’re registered in our APAC data region (https://apac.smith.langchain.com/) so the API URL you’d need is: https://apac.api.smith.langchain.com

Documentation for reference:

Please let me know if that works for you.

Best,
Chad

3

Update: this fixed it, thank you!

For anyone else who lands here with the same issue - I’m based in the APAC region, and switching my LANGSMITH_ENDPOINT from the default https://api.smith.langchain.com to https://apac.api.smith.langchain.com resolved the 403 immediately. No other changes were needed - same API key, same workspace ID, same project name all worked fine once pointed at the correct regional endpoint.

For context, before this fix I’d ruled out: invalid/corrupted keys, both Personal and Service key types, billing/usage limits, workspace scoping, and even bypassed the SDK entirely with a raw curl request - all returned the same generic 403 Forbidden. So if anyone else is stuck on an unexplained 403 despite everything checking out, and you’re outside the US, this regional endpoint is worth checking early - would have saved me a lot of time.

Thanks again for pointing me in the right direction!