Quickstart

Make one optimize call with a partner key, then make the same call paid per request with x402 in USDC on Base.

This page rebalances 1,000 USDC on Base across seven lending markets. The request is identical for both auth methods; only the headers change.

The request

Amounts are base units. USDC on Base has 6 decimals, so 1000000000 is 1,000 USDC and 500000000 is 500 USDC.

{
  "total_capital": "1000000000",
  "token_address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "current_allocations": { "aave": "500000000", "compound": "500000000" },
  "protocols": ["aave", "compound", "moonwell", "fluid", "euler_usdc", "spark", "superform"],
  "wallet_address": "0xYourWallet"
}

Save it as request.json. The market names in protocols must come from the market list for the same chain and token.

With a partner key

1. Send the call

   curl -s https://si.ampli.net/api/v1/optimizer/8453/optimize \
     -H "Content-Type: application/json" \
     -H "X-Partner-Name: your-partner-name" \
     -H "X-Partner-API-Key: $AMPLI_PARTNER_API_KEY" \
     -d @request.json
   
2. Read the plan

   The response has three parts: optimization_result (the target allocation and APR before and after), action_plan (withdrawals first, then deposits), and calldata (one entry per transaction, in order). See Optimize for every field.

3. Execute with your own wallet

   Check the plan, then sign and send each calldata entry in order from wallet_address. Ampli never signs or sends anything.

With x402

Leave out the partner headers. The first response is 402 Payment Required with a PAYMENT-REQUIRED header that carries the price in USDC base units on Base (eip155:8453). An x402 client signs an EIP-3009 authorization and retries with PAYMENT-SIGNATURE. It needs no gas and no prior approval, only USDC on Base in the paying wallet.

TypeScript

pnpm add @x402/fetch @x402/evm viem

import { readFileSync } from "node:fs";
import { decodePaymentResponseHeader, wrapFetchWithPaymentFromConfig } from "@x402/fetch";
import { ExactEvmScheme } from "@x402/evm";
import { privateKeyToAccount } from "viem/accounts";

// The paying wallet's own signer. Ampli never sees this key.
const payer = privateKeyToAccount(process.env.PAYER_PRIVATE_KEY as `0x${string}`);

const fetchWithPayment = wrapFetchWithPaymentFromConfig(fetch, {
  schemes: [{ network: "eip155:8453", client: new ExactEvmScheme(payer) }],
});

const response = await fetchWithPayment("https://si.ampli.net/api/v1/optimizer/8453/optimize", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: readFileSync("request.json", "utf8"),
});

const plan = await response.json();
const receipt = response.headers.get("PAYMENT-RESPONSE");
console.log(plan.action_plan, receipt ? decodePaymentResponseHeader(receipt) : null);

Raw HTTP

# 1. Ask without payment. Expect 402 and a PAYMENT-REQUIRED header (base64 JSON).
curl -si https://si.ampli.net/api/v1/optimizer/8453/optimize \
  -H "Content-Type: application/json" -d @request.json

# 2. Sign the offer with an x402 client, then retry with the signed payload.
curl -si https://si.ampli.net/api/v1/optimizer/8453/optimize \
  -H "Content-Type: application/json" \
  -H "PAYMENT-SIGNATURE: <base64 payment payload>" \
  -d @request.json

Mistakes are free

The payment is verified before the work and settled only on a 2xx response. A 400 for a bad constraint or a 422 for an over-allocated book costs nothing.

Next

• Authentication and payments for the full 402 offer and receipt.
• Risk rules to understand why a market got less than you expected.
• API MCP to call the same thing as an MCP tool.