The First Five Minutes: What Onboarding Actually Looks Like

The best test of any payment platform is the time from landing page to first successful API call. On MoltPe, that clock runs short on purpose. You sign up with email or GitHub OAuth. There is no email verification wall in the way of the dashboard — you land on it immediately and can click around. There is no KYC modal for developer accounts. There is no credit card requirement to start. The free tier is usable, not a teaser.

The dashboard opens to a single call-to-action: Create your first agent wallet. One click provisions an isolated wallet on Polygon PoS (the default, chosen because gas is effectively free on the MoltPe paymaster). You name it something like research-agent and the wallet address and a testnet USDC balance appear immediately. No waiting on block confirmations to start building.

The next panel shows your API key. It is displayed once, with a clear warning, and you can copy it in one click. Below the key is a ready-to-paste curl command wired to your actual wallet ID — not a generic placeholder you have to fill in:

curl https://api.moltpe.com/v1/wallets/wlt_7f3a2b1c/balance \
  -H "Authorization: Bearer mpk_live_9f2a4c..."

Paste, run, get a real JSON response with your balance. That is the five-minute path. And critically: the first API call works on the first try because if something does fail, the error tells you exactly what is missing, which is the next section.

Error Messages Designed for Debugging

Most payment APIs treat errors as an afterthought. You get {"error":"bad request"} and are invited to re-read a 40-page reference to figure out which of your forty fields is at fault. MoltPe takes the opposite position: the error response is the single most important thing the API returns, because a working response is forgettable but a broken one is where your day stops.

Every error includes a machine-readable code, a human message, a fix hint pointing to the exact remediation, and a docs_url. Three real examples:

Missing auth header:

HTTP/2 401 Unauthorized
Content-Type: application/json

{
  "error": {
    "code": "auth_missing_header",
    "message": "No Authorization header was sent with this request.",
    "fix": "Add 'Authorization: Bearer YOUR_API_KEY' to the request. You can find your key in the dashboard under Settings → API Keys.",
    "docs_url": "https://moltpe.com/guide#authentication",
    "request_id": "req_01HZ8K4NTQV9"
  }
}

Insufficient balance:

HTTP/2 402 Payment Required
Content-Type: application/json

{
  "error": {
    "code": "insufficient_balance",
    "message": "Wallet wlt_7f3a2b1c cannot cover this payment.",
    "fix": "Top up the wallet by at least 0.47 USDC and retry. Minimum buffer to account for gas sponsorship headroom is 0.01 USDC.",
    "wallet_balance_usdc": "1.23",
    "required_usdc": "1.70",
    "shortfall_usdc": "0.47",
    "docs_url": "https://moltpe.com/guide#topping-up",
    "request_id": "req_01HZ8K4NWR3P"
  }
}

Policy block:

HTTP/2 403 Forbidden
Content-Type: application/json

{
  "error": {
    "code": "policy_blocked",
    "message": "Payment blocked by policy 'daily_cap_5_usdc'.",
    "fix": "Raise the policy cap in the dashboard or wait for the rolling window to reset at 00:00 UTC.",
    "policy_name": "daily_cap_5_usdc",
    "policy_current_usage_usdc": "4.82",
    "policy_cap_usdc": "5.00",
    "policy_window_reset_at": "2026-04-21T00:00:00Z",
    "docs_url": "https://moltpe.com/guide#spending-policies",
    "request_id": "req_01HZ8K4NY2XF"
  }
}

Every one of those is something you can act on without opening a second browser tab. That is the bar.

Docs and Discoverability

The MoltPe API docs are hand-written, not auto-generated from a schema dump. Each endpoint has a plain-English explainer, a request example, a response example, and a failures section listing every error code that endpoint can return with a sample body. No hunting in a separate "errors" page.

There is a dedicated quickstart per protocol: a REST quickstart for classic request-response, an x402 quickstart for HTTP-native micropayments, and an MCP quickstart for agent tool calls. You only read the one you are using. Code examples render in three languages side by side: Node.js, Python, and curl. You pick your tab, copy, and go.

The glossary is searchable and cross-linked. If a page mentions "paymaster" or "ERC-4337," the term links straight to its definition. The FAQ is organized by persona (founder, developer, finance) rather than by feature, so you find your question by who you are, not by guessing which section of the product it lives in. Dark mode ships on by default — the audience is developers — with a toggle for the minority who prefer light.

Testing Without Real Money

MoltPe runs full testnet parity on Polygon Amoy and Base Sepolia. Any mainnet feature works on testnet, including x402, MCP, webhooks, and policies. Test USDC is dispensed from a faucet-style endpoint in the dashboard — one click, no forms, funds arrive in seconds.

The critical design choice: spending policies are still enforced on testnet. If your production policy caps per-transaction at $0.50, the same cap hits your testnet wallet. That means the agent behavior you validate in staging is the behavior you get in production — a policy bug in test is a policy bug you would have shipped. No "works in dev, fails in prod" class of surprise.

Switching a wallet between testnet and mainnet is a single flag on the wallet object ("network_mode": "mainnet" or "testnet"). Your application code changes one field. No separate API hostnames, no separate key types, no config gymnastics. In CI you flip the flag per run; in production, you set it once.

MCP Integration Specifics

The MoltPe MCP server drops into Claude Desktop, Cursor, and Windsurf with a single config block. Here is the Claude Desktop entry:

{
  "mcpServers": {
    "moltpe": {
      "command": "npx",
      "args": ["-y", "@moltpe/mcp-server"],
      "env": {
        "MOLTPE_API_KEY": "mpk_live_9f2a4c..."
      }
    }
  }
}

Restart the host, and the agent has tools. Tool names are written for the agent that will call them, not for brevity: create_agent_wallet, check_balance, send_payment, call_x402_endpoint, list_transactions, agent_info. No cryptic cAW or sp. An agent reading the tool list can reason about which one to call without a separate prompt explaining the abbreviations.

Tool responses include structured data the model can reason over downstream. A check_balance call does not just return a number — it returns balance, USD-equivalent, last transaction timestamp, and the address. A send_payment call returns the on-chain hash, the block explorer URL, and the post-transaction balance in one response, so the next model turn has everything it needs.

Authentication uses your MoltPe API key, scoped strictly to your agents. An agent running under your key cannot see, move, or impersonate another developer's wallets — the server-side scope check happens before the tool even executes. The full tool surface is documented with example request/response pairs on the MCP quickstart page.

Rate Limits and Scaling

The free tier allows 60 requests per minute and 10,000 requests per day per API key — generous enough that you will not hit it during development, local testing, or a first production pilot. Paid tiers lift those limits substantially and add dedicated rate-limit pools so a noisy agent does not starve a quiet one.

When you do hit a limit, the response is explicit and actionable:

HTTP/2 429 Too Many Requests
Retry-After: 14
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1713628814
Content-Type: application/json

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Rate limit of 60 requests per minute exceeded.",
    "fix": "Wait 14 seconds and retry, or upgrade your plan for higher limits.",
    "docs_url": "https://moltpe.com/guide#rate-limits"
  }
}

The Retry-After header is honored by most HTTP client libraries automatically — you usually do not have to write retry logic yourself. Long-running operations (batch payouts, bulk policy updates) return immediately with an operation_id you poll against /v1/operations/{id}. No holding HTTP connections open for thirty seconds and hoping the load balancer agrees.

What the Support Flow Looks Like

Three channels, all public or near-public, none gated behind an enterprise sales call. GitHub Issues on the moltpe org is the fastest way to reach engineering — issues are triaged daily and answered in-thread. Twitter DM at @moltpe is open for quick questions and works best for "is this a known issue?" or "which endpoint should I use?" A feedback button on every docs page files a tagged report that routes straight to the docs maintainer.

Paid plans add a shared Slack Connect channel with the team, and enterprise adds a dedicated engineer. But nothing critical — no bug fix, no outage update, no API clarification — is locked behind a tier. If the product is broken for a free-tier developer, it gets fixed for a free-tier developer.