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.

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

1

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
Response (abbreviated):
{
  "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
  }
}
2

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

Browse services →

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

Browse capabilities →

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.

3

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.

Best for: default production path

x402 Payment

Zero-signup, per-call USDC payment when request-level payment authorization is the point.

Best for: zero-signup per-call auth

Wallet Prefund

Wallet-auth once, top up reusable balance, execute with X-Rhumb-Key.

Best for: repeat wallet traffic

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, enterprise

Execute 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.

4

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 →

Keep going