Quickstart
First call in 30 seconds
No signup required. Copy a command, get a response. Read endpoints are free and open.
Before you wire this deeper
Want to evaluate the trust story first? Read Trust, inspect the public Methodology, or use the provider dispute path if a score or claim looks wrong.
Route picker
Pick the path that matches why you are here
This page is the curl-first path, but cold-start builders and operators should not have to infer that. Evaluators start on free reads. Agent builders start with MCP. Teams that want governed repeat execution start with account setup and X-Rhumb-Key.
Evaluator path
Evaluating with curl
Start with the free read endpoints. See real responses, learn the product model, and judge the trust layer before signup.
Best when you are sizing up Rhumb, sharing a first link, or validating the discovery story with minimal setup.
Start here →Builder path
Building an agent
Install the MCP server or use the starter prompt. Reach for capability IDs when the agent needs executable actions, not just vendor names.
Best when Claude, Codex, Cursor, or another runtime already speaks tools and should keep Rhumb inside the loop.
Start here →Operator path
Need an account and reusable key
Sign up for identity, add credits, then execute with X-Rhumb-Key. Signup creates the account. Funding unlocks governed execution.
Best when you want managed routing, dashboard controls, spend visibility, and repeat traffic on one stable key.
Start here →Best first win
Rhumb is strongest today for research, extraction, generation, and narrow enrichment. If you want a clean first success, start there.
Don’t overread the promise
If you are wiring multi-system back-office workflows, use Rhumb as capability infrastructure first. Don’t assume the current product is already a general business-automation layer.
Mental model
Use one default path unless you have a reason not to
Default path: start with governed API key or wallet-prefund on `X-Rhumb-Key`, discover a Service, choose a Capability, estimate the call, then execute through Layer 2. Start with Rhumb-managed superpowers first. Bring BYOK or Agent Vault only when the workflow touches your own systems. Use x402 only when zero-signup per-call matters. Use Layer 1 only when you must pin the provider. Use Layer 3 only when a published recipe already exists.
Think in entities
Service = vendor. Capability = executable action. Recipe = compiled workflow.
Default layer
Start with Layer 2: capability routing. It is the cleanest real production surface today.
Default auth rail
Use governed API key or wallet-prefund on X-Rhumb-Key for repeat calls. Bring BYOK or Agent Vault only when provider control is the point. Use x402 only when zero-signup per-call payment is the point.
Canonical docs
Full map: /docs#resolve-mental-model
Try the API
All read endpoints are free, no key required. Pick your language:
curl
curl "https://api.rhumb.dev/v1/services/stripe/score" JavaScript
const res = await fetch("https://api.rhumb.dev/v1/services/stripe/score");
const { data } = await res.json();
console.log(data.an_score); // 8.1 Python
import requests
data = requests.get("https://api.rhumb.dev/v1/services/stripe/score").json()["data"]
print(data["an_score"]) # 8.1 {
"data": {
"slug": "stripe",
"an_score": 8.1,
"tier": "L4 Native",
"execution_score": 8.4,
"access_readiness_score": 7.3,
"failure_count": 2,
"review_count": 47
}
} Explore by vendor or by job
Do not force one endpoint to answer two different questions. /search
tells you which services look best. /capabilities?search= tells you which executable action IDs Rhumb already understands.
Service discovery
Use services when you are choosing who to trust
Service search answers the vendor question. It returns scored services, not executable action IDs.
curl "https://api.rhumb.dev/v1/search?q=web+search"curl "https://api.rhumb.dev/v1/leaderboard/research"curl "https://api.rhumb.dev/v1/services/brave-search" Capability discovery
Use capabilities when you know the job but not the slug
Capability search answers the action question. It returns IDs like search.query and email.send, then points you into resolve and estimate.
curl "https://api.rhumb.dev/v1/capabilities?search=web+research"curl "https://api.rhumb.dev/v1/capabilities/search.query/resolve"curl "https://api.rhumb.dev/v1/capabilities/search.query/execute/estimate" Mental shortcut
Service = vendor to evaluate. Capability = action to execute. If the question is “who should I use?”, search services. If the question is “what exact action slug do I call?”, search capabilities.
Resolve then estimate
Read resolve as the ranked recommendation. Read estimate as the concrete provider on the rail you are actually about to use. They answer different questions on purpose.
Execute through governed API key first
For the cleanest first paid success, start with a Rhumb-managed capability behind X-Rhumb-Key. Sign up creates identity. Credits or wallet-prefund unlock governed execution. Prove the managed Layer 2 path first, then bring BYOK or Agent Vault only when the workflow crosses into your CRM, support, data, or ops systems.
Lowest-heroics first win
# 1) Resolve a managed capability
curl "https://api.rhumb.dev/v1/capabilities/search.query/resolve"
# 2) Estimate before paying
curl "https://api.rhumb.dev/v1/capabilities/search.query/execute/estimate"
# 3) Execute through Layer 2 with your governed API key
curl -X POST "https://api.rhumb.dev/v1/capabilities/search.query/execute" -H "X-Rhumb-Key: rhumb_live_..." -H "Content-Type: application/json" -d '{"body": {"query": "best CRM for seed-stage B2B SaaS", "max_results": 5}}' Bring bridges later
Keep the same Resolve flow when you move into Salesforce, HubSpot, Zendesk, Postgres, GitHub, or other operator-owned systems. The change is the credential path, not the product mental model.
Same flow, different capability
# 1) Discover the capability you need
curl "https://api.rhumb.dev/v1/capabilities?search=email"
# 2) Resolve ranked providers, or follow the machine-readable recovery handoff
curl "https://api.rhumb.dev/v1/capabilities/email.send/resolve?credential_mode=byok"
# 3) Estimate before paying
curl "https://api.rhumb.dev/v1/capabilities/email.send/execute/estimate"
# 4) Execute through Layer 2 with X-Rhumb-Key
curl -X POST "https://api.rhumb.dev/v1/capabilities/email.send/execute" -H "X-Rhumb-Key: rhumb_live_..." -H "Content-Type: application/json" -d '{"body": {"to": "user@example.com", "subject": "Hello", "body": "Hi from Rhumb"}}'
If the requested rail dead-ends, Resolve returns machine-readable recovery fields like recovery_hint.resolve_url, recovery_hint.credential_modes_url, and, when applicable, recovery_hint.alternate_execute_hint or recovery_hint.setup_handoff instead of forcing another discovery pass. If the capability ID is wrong, you get search suggestions rather than a blank dead end.
Governed API key
Sign up, add credits, then pass the key as X-Rhumb-Key.
x402 Payment
Zero-signup, per-call USDC payment when request-level payment authorization is the point.
Best for: zero-signup per-call authWallet Prefund
Wallet-auth once, top up reusable balance, execute with X-Rhumb-Key.
BYOK / Agent Vault
Use BYOK for direct pass-through, or Agent Vault for encrypted provider credential injection when provider control is the point.
Best for: teams, enterpriseExecute via governed API key
curl -X POST "https://api.rhumb.dev/v1/capabilities/email.send/execute" \
-H "X-Rhumb-Key: rhumb_live_..." \
-H "Content-Type: application/json" \
-d '{"body": {"to": "user@example.com", "subject": "Hello", "body": "Hi from Rhumb"}}' Execute via wallet-prefund
# Step 1: Prove wallet control and create wallet session
curl -X POST "https://api.rhumb.dev/v1/auth/wallet/request-challenge" -H "Content-Type: application/json" -d '{"chain":"base","address":"0x...","purpose":"access"}'
curl -X POST "https://api.rhumb.dev/v1/auth/wallet/verify" -H "Content-Type: application/json" -d '{"challenge_id":"...","signature":"0x..."}'
# Returns wallet session + wallet-scoped X-Rhumb-Key credential
# Step 2: Top up reusable balance via x402 settlement
curl -X POST "https://api.rhumb.dev/v1/billing/x402/topup/request" -H "Authorization: Bearer <wallet_session_token>" -H "Content-Type: application/json" -d '{"amount_usd": 1.00}'
# ...settle + verify through /billing/x402/topup/verify...
# Step 3: Execute repeat calls with X-Rhumb-Key (no per-call X-Payment)
curl -X POST "https://api.rhumb.dev/v1/capabilities/email.send/execute" -H "X-Rhumb-Key: rhumb_live_..." -H "Content-Type: application/json" -d '{"body": {"to": "user@example.com", "subject": "Hello"}}' Execute via x402 (zero signup)
# Step 1: Request execution without a governed API key
curl -X POST "https://api.rhumb.dev/v1/capabilities/email.send/execute" \
-H "Content-Type: application/json" \
-d '{"body": {"to": "user@example.com", "subject": "Hello"}}'
# Returns 402 with the exact asset, amount, address, and network to pay
# Step 2: Pay the exact requirement from your wallet
# Double-check asset + network + destination address before sending funds
# Step 3: Retry with payment proof from the same wallet
curl -X POST "https://api.rhumb.dev/v1/capabilities/email.send/execute" \
-H 'X-Payment: {"tx_hash":"0x...","network":"<network-from-402>","wallet_address":"0x..."}' \
-H "Content-Type: application/json" \
-d '{"body": {"to": "user@example.com", "subject": "Hello"}}' Honest note
The repeatable public x402 execute path today is tx-hash proof. Wallet-prefund top-up verification is the standard x402 authorization path; direct execute is not. Some smart-wallet or wrapped authorization payloads still hit a production compatibility boundary on the direct execute rail because the facilitator path is not wired. If your buyer emits wrapped proofs, switch to wallet-prefund or use the standard governed API key rail.
Connect via MCP
If your agent supports MCP, connect directly:
Install
npx rhumb-mcp@latest Claude Desktop config
{
"mcpServers": {
"rhumb": {
"command": "npx",
"args": ["rhumb-mcp@latest"],
"env": {
"RHUMB_API_KEY": "rhumb_live_..."
}
}
}
} 21 tools available: find_services,
get_score,
get_alternatives,
get_failure_modes,
execute_capability, and more.
Full MCP guide →