Skip to main content

Barndoor SDK

A lightweight, framework-agnostic Python client for the Barndoor Platform REST APIs and Model Context Protocol (MCP) servers. The SDK removes boiler-plate around:
  • Secure, offline-friendly authentication to Barndoor (interactive PKCE flow + token caching).
  • Server registry – list, inspect and connect third-party providers (Salesforce, Notion, Slack …).
  • Managed Connector Proxy – build ready-to-use connection parameters for any LLM/agent framework (CrewAI, LangChain, custom code …) without importing Barndoor-specific adapters.

Download here: https://pypi.org/project/barndoor/


How it works

The SDK orchestrates a multi-step flow to connect your code to third-party services:
  1. Authentication: You log in via Barndoor to get a JWT token
  2. Registry API: Using the JWT, query available MCP servers and manage OAuth connections
  3. MCP Proxy: Stream requests through Barndoor’s proxy with the JWT for authorization
  4. Third-party service: The proxy forwards your requests to Salesforce, Notion, etc.
This architecture provides secure, managed access to external services without handling OAuth flows or storing third-party credentials in your code.

Installation

Python ≥ 3.10 is required.

Local development with uv

For the fastest install and reproducible builds you can use uv instead of pip.
Note: The OAuth default callback uses port 52765. Make sure this is registered in your Barndoor Agent as:

Using a custom OAuth callback port

If port 52765 is blocked (or you prefer another), you can:
  1. Register the new callback URL in your Barndoor Agent application, e.g.
  2. Run the login helper with the matching port
The SDK will spin up the local callback server on that port and embed the new URL in the request. The examples expect a .env file next to each script containing:

Authentication workflow

Barndoor APIs expect a JWT issued by your Barndoor tenant. The SDK offers three ways to obtain such a token: The interactive variants:
  1. Spin up a tiny localhost callback server.
  2. Open the system browser to Barndoor.
  3. Exchange the returned code for a JWT.
  4. Persist the token to ~/.barndoor/token.json (0600 permissions).
Environment variables (or a neighbouring .env file) must define the Agent OAuth application:
The cached token is auto-refreshed on every run; if it is expired or revoked a new browser flow is launched.

Machine-to-machine (client credentials)

For headless services with no user present, use the standard OAuth 2.0 client-credentials grant. This requires a Barndoor OAuth application configured for the client-credentials grant type. The SDK exposes a one-call factory, BarndoorSDK.from_client_credentials(...), that fetches the initial JWT, refreshes it automatically as it nears expiry, and transparently retries once on 401 Unauthorized.
Prefer the issuer= keyword argument (OIDC discovery finds the token endpoint automatically). The legacy domain= keyword is retained for backwards compatibility and posts directly to https://{domain}/oauth/token. If you only need the raw access token (e.g. to inject it into another HTTP client), use the lower-level helpers re-exported from barndoor.sdk:
These return only the access-token string and do not persist anything to ~/.barndoor/token.json. Use the from_client_credentials factory if you want the SDK to manage token lifetime for you. A complete runnable example is at examples/sample_m2m_client.py.

Quick-start in four lines

params is a plain dict with url, headers and (optionally) transport – ready to plug into any HTTP / SSE / WebSocket client. See the examples below for CrewAI & LangChain usage.

Using the Registry API

Additional helpers:
  • await sdk.initiate_connection(server_id) – returns an OAuth URL the user must visit.
  • await bd.ensure_server_connected(sdk, "notion") – combines status polling + browser launch.

Model Context Protocol Connection

Once a server is connected you can stream requests through Barndoor’s proxy edge.

API Documentation

The complete API specification is available in barndoor/sdk/docs/openapi.yaml. This covers all endpoints currently used by the SDK including:
  • Server listing and details
  • OAuth connection initiation
  • Connection status checking
The spec can be viewed with tools like Swagger UI or Redoc.