Plug Blockchain0x into your agent stack.
Real code for every popular agent framework. A shipped package where one exists, a short SDK recipe where it does not.
Pick your framework. Where we ship a package you install it; otherwise you wrap our SDK in that framework's native tool. Either way it is a thin layer over one HTTP API, and you can skip it and call the API directly.
Each card opens a deep-dive: the install or the recipe, a working agent example, webhook handling, and common pitfalls. Three ship as real packages today - blockchain0x-langchain and blockchain0x-crewai on PyPI, and @blockchain0x/mcp on npm. The other seven are short recipes over the same SDK. No invented package.
Ten frameworks. Three packages, seven recipes, one API.
LangChain
PyPI packagePython toolset from the blockchain0x-langchain package; TypeScript agents wrap the x402 client
CrewAI
PyPI packagePython toolset from blockchain0x-crewai, the same factory shape as LangChain
AutoGen
SDK recipeRecipe: wrap the SDK in an AutoGen function tool
LlamaIndex
SDK recipeRecipe: wrap the client in a LlamaIndex FunctionTool
OpenAI Agents SDK
SDK recipeRecipe: wrap the client in an OpenAI Agents SDK function tool
Pydantic AI
SDK recipeRecipe: register a Pydantic AI tool that calls the client
LangGraph
SDK recipeRecipe: a LangGraph node that calls the x402 client
Semantic Kernel
SDK recipeRecipe: a KernelFunction wrapping the SDK; no NuGet or Java adapter
Agno
SDK recipeRecipe: an Agno Toolkit wrapping the Python client
MCP servers
npm packageWallet tools for any MCP client through the @blockchain0x/mcp server
Agent Skill
Agent SkillOne installable Agent Skill that teaches any AI agent the whole wallet integration surface; portable or via the Claude Code plugin marketplace
A consistent shape across every framework.
- The install command for the package, or the recipe when there is no package
- Copy-paste code you can run, not pseudocode
- A short answer to 'how do I add payments to my {framework} agent'
- FAQ entries with HowTo/FAQ schema for AI search engines
- A link to the matching long-tail landing page
- A link to the pricing page
Every integration is a thin wrapper over the same API.
The Blockchain0x integrations are not 10 separate products. They are 10 different ergonomic surfaces on top of a single HTTP API. The API is the source of truth; the framework wrappers exist to save you time.
Each wrapper translates from "the way your framework defines a tool" into "an HTTP call to our API". That is the entire job. The Python adapters expose create_blockchain0x_toolset(client), which hands LangChain or CrewAI a ready-made set of tools. A framework without a shipped adapter wraps createX402Client(...) (Node) or the blockchain0x client (Python) in a native tool of that framework. Same API underneath, either way.
This matters for a few reasons. First, you can mix and match: a LangChain production agent and a CrewAI experimental agent can both target the same Blockchain0x agent wallet without conflict. Second, you are not locked into a framework choice through us; switching frameworks does not require any change to your wallet, your spend policies, or your public page. Third, when we ship a new endpoint or a new webhook event, the framework wrappers expose it on their next release; the underlying API is the contract.
You can integrate without our SDK, our wrapper, or our framework integration.
The Blockchain0x API is plain JSON over HTTPS with bearer-token auth. Any HTTP client in any language can call it. The official SDKs and framework wrappers are convenience layers; the raw API is documented, stable, and intentionally small enough that hand-writing against it is reasonable.
curl -X POST https://api.blockchain0x.com/v1/payments \ -H "Authorization: Bearer $BLOCKCHAIN0X_API_KEY" \ -H "Idempotency-Key: $(uuidgen)" \ -H "Content-Type: application/json" \ -d '{ "agentId": "<your-agent-id>", "to": "0xRecipientAddress", "amountWei": "100000", "metadata": { "reason": "Custom market analysis" } }'
When skipping the SDK makes sense
- You are in a language we do not ship. Go, Rust, Elixir, Ruby, PHP, Java - all of these can call our API natively with their standard HTTP libraries. No special tooling required.
- You are on the edge. Cloudflare Workers, Vercel Edge Functions, Deno Deploy - environments where you would rather not bundle an extra dependency. The raw API works there without changes.
- You want to see exactly what is on the wire. For debugging, security review, or learning the protocol, the raw HTTP shape is clearer than reading SDK source.
- You have your own HTTP layer with retries, logging, telemetry. Bringing in another SDK with its own retry behavior fights your existing infrastructure. Calling the raw API as just another HTTP endpoint slots in cleanly.
The full API reference at docs.blockchain0x.com includes the OpenAPI spec, so you can also generate your own client in any language that has an OpenAPI codegen tool.
When each framework is the right tool.
If you have not picked an agent framework yet, here is how we see the trade-offs. None of these are wrong choices; the right one depends on what your agent does and who maintains it.
| Framework | Best when | Avoid when |
|---|---|---|
| LangChain | Existing LangChain codebase, complex tool chains, broad ecosystem use | You want minimal dependencies; LangChain pulls in a lot |
| LangGraph | Stateful multi-step workflows, durable execution, human-in-the-loop | Simple linear chains; the graph overhead is wasted |
| CrewAI | Multi-agent collaboration patterns (researcher + writer + reviewer) | Single-agent loops; CrewAI is built for crews |
| AutoGen | Multi-agent conversation, group chat patterns, Microsoft tooling | Production high-throughput; AutoGen optimizes for research |
| LlamaIndex | RAG-heavy agents, document Q+A as core capability | Pure tool-use agents; LlamaIndex's strengths go unused |
| OpenAI Agents SDK | OpenAI-only stacks, want the cleanest tool-use API | Multi-provider stacks; OpenAI SDK is OpenAI-centric |
| Pydantic AI | Strong typing across all agent inputs/outputs, Python-first | TypeScript-first stacks; the Python-native typing is the value |
| Semantic Kernel | Existing .NET / C# / Java codebase, enterprise Microsoft shop | Python-only teams; you are paying for unused MS integration |
| Agno | Python-native, lightweight, want minimal abstraction overhead | You need the LangChain ecosystem's third-party integrations |
| MCP middleware | You are running an MCP server and want clients to pay per call | You are not running an MCP server (it is a server-side pattern) |
Two practical pieces of advice. If you are starting from scratch and want the smallest possible learning curve, LangChain or OpenAI Agents SDK are the safest defaults. If you already have a framework, our integration for it works fine; do not switch frameworks just to use Blockchain0x.
Specific scenarios get their own page.
Beyond the framework-specific integration pages, we publish long-tail guides on narrower questions: "how do I add payments to a LangGraph multi-step workflow", "how do I let my MCP server charge per tool", "how do I gate a Stripe-like API behind USDC payment". These live at /lp/{slug} and are intentionally not in the main navigation. They get found through search; each links back to the relevant integration page.
Where to find them
The first batch of long-tail guides ships alongside the integration framework pages. Until then, the most concrete scenario-specific content lives in the docs at docs.blockchain0x.com under "Guides". Each /lp/ page includes working code you can run and a direct CTA to upgrade the relevant agent to Pro.