How it works

Six steps from await routeweiler.get(url) to a paid response.

Routeweiler sits between your AI agent and the target API, routing payments across x402, L402, MPP-Tempo, and MPP-SPT rails, and emitting traces to local SQLite.

Six responsibilities

  1. 1

    Intercept 402

    When a server responds with 402 Payment Required, routeweiler parses the payment challenge into a single normalised shape.

  2. 2

    Enforce policy

    A declarative Policy object lets you allow, deny, or preference rails per URL pattern, network, or amount.

  3. 3

    Route

    Routeweiler filters rails by policy and by available funding, then picks the cheapest quote in your envelope currency.

  4. 4

    Enforce budget

    BudgetEnvelope defines a spending cap, currency, TTL, and allowed rails. Overspend is impossible within a single process.

  5. 5

    Pay and retry

    Payment is signed entirely client-side. The signed proof is attached as an Authorization header and the original request is retried against the same URL.

  6. 6

    Emit trace

    Every payment attempt writes a structured TraceEvent to local SQLite. No data leaves the process.

Payment rails

Rail Protocol Settlement Funding source
x402 EVM signed transfer On-chain USDC (Base, Ethereum) Funding.base_usdc(wallet=…)
l402 BOLT-11 Lightning sats Funding.lightning_lnd(client=…)
mpp-tempo Tempo 0x76 transaction PathUSD / USDC Funding.tempo_usdc(wallet=…)
mpp-spt Stripe Shared Payment Token Fiat card Funding.stripe(api_key=…, …)

Non-custodial by design

Keys never leave your process. Routeweiler signs transactions using the key material you pass in. It does not store, escrow, or transmit private keys. The only data that persists is the local SQLite trace, which stays on the machine running your agent.

This keeps Routeweiler outside money-transmitter and CASP regulatory scope. You own the keys; you own the funds; you own the audit log.