Skip to main content

Sell With Your Agent: Zero to a Paid API

You already activated a Lightning Enable account (the previous step). This guide is the next one: turn that account into a paid, agent-discoverable endpoint without touching the dashboard or writing any integration code yourself.

The producer-setup skill drives the whole thing through the Lightning Enable MCP server. You give your agent three things and one sentence; it does the rest — configuring your receive lane, wrapping your API, publishing a machine-readable manifest, and proving the whole path works with a real, tiny Lightning payment before it tells you it's done.

Works wherever the MCP server runs

Claude Code, Claude Desktop, or any MCP-compatible agent host with the Lightning Enable MCP connected and a merchant API key set (LIGHTNING_ENABLE_API_KEY). If you don't have a key yet, activate one for free with a ~100-sat L402 payment — no card. setup_wallet and l402_producer ship in the default standard tool profile — nothing extra to enable.

What you provide​

Three things, and the agent needs no more from you than this:

You provideWhy
A wallet to receive payments — a Nostr Wallet Connect (NWC) connection string from a wallet you already run (CoinOS, Alby Hub, or another NIP-04 wallet), or a Strike/OpenNode API keyThis is where the sats your endpoint earns land. Lightning Enable never touches it beyond asking for an invoice and asking later whether it was paid.
A spend ceiling for the agent's own wallet — a dollar or sat cap, e.g. "$5 max"The agent pays a tiny self-test challenge against your new endpoint before handing it back to you, so it needs a small amount of its own spending room. This is the same budget mechanism documented in AI Spending Security — the wallet balance and the config-file caps are the real ceiling, not the agent's judgment.
The API to monetize, and a price — a base URL and a sats-per-call figureWhat gets wrapped and what it costs. Any HTTPS API works; see Setting Up Your Proxy for the constraints (no raw IPs, no internal hostnames, standard ports only).

The one sentence​

This is the literal instruction — say it to your agent once the MCP server is connected:

Set me up to sell my API over Lightning: use the wallet you already have connected to receive payments, keep the signup and self-test under 200 sats, charge 25 sats per call on https://api.mycompany.com/v1/forecast, publish it, and show me the OpenAPI URL and the challenge feed when you are done.

Swap in your own connection string, URL, and price. If you're paying with Strike or OpenNode instead of NWC, say "using my Strike API key" — the skill accepts either.

What the skill does, step by step​

The skill calls the Lightning Enable MCP tools in this order. Nothing here requires you to open the dashboard.

  1. setup_wallet — if the agent doesn't already have a paying wallet configured, this writes ~/.lightning-enable/config.json with a small wallet and the spend ceiling you gave it. This is the wallet the agent uses in step 7 to pay its own self-test challenge — it is separate from the receive-side wallet in the next step.
  2. l402_producer(action="configure_receive", ...) — saves your receive-side credential and switches your account onto that lane. For NWC this wraps PUT /api/merchant/nwc-connection followed by PUT /api/merchant/payment-provider; for Strike/OpenNode it wraps the equivalent key endpoint. See Nostr Wallet Connect setup for what this credential looks like and what it can and can't do.
  3. l402_producer(action="status") — confirms the receive lane actually took (provider set, credential present, reachable) before anything downstream depends on it. Cheap, read-only, and worth insisting the agent check before it moves on.
  4. l402_producer(action="create_proxy", ...) — wraps your API in an L402-gated proxy pointed at the target URL and default price (POST /api/proxy).
  5. l402_producer(action="add_endpoint", ...) — registers the specific path, method, summary, and price you asked for so it's visible in the manifest with its own description, not just the proxy's default fallback price.
  6. l402_producer(action="publish", ...) — turns on the manifest and (if you asked for discoverability) lists it in the public L402 registry.
  7. l402_producer(action="create", ...) then a payment from the wallet configured in step 1 — the skill mints a one-off, tiny challenge against your brand-new endpoint and pays it itself, inside the spend ceiling you set.
  8. l402_producer(action="verify", ...) — verifies its own payment. This is the same cryptographic check any real buyer's payment goes through: SHA256(preimage) == payment_hash, macaroon signature valid, not expired. A valid: true here means a stranger paying the same way would also get in.
  9. l402_producer(action="list_challenges") — pulls the challenge feed back so you can see the self-test entry as a receipt, not just take the agent's word for it.

If any step fails, the skill stops and reports which one — it does not silently retry into a different configuration than the one you asked for.

What you get back​

At the end of a successful run, the agent hands you four things:

  • An OpenAPI document at /l402/proxy/{proxyId}/openapi.json — every visible endpoint carries an x-payment extension (price in sats, supported payment protocols, token validity window) and a 402 response pointing at the L402 challenge shape. Point any OpenAPI-aware tool at this URL directly.
  • A manifest at /l402/proxy/{proxyId}/.well-known/l402-manifest.json — the L402-native discovery document other agents read to learn what your API does and what it costs. Both documents describe the same endpoints from the same pricing logic; they can't disagree.
  • A challenge listing — GET /api/l402/challenges?status=paid shows every payment your endpoint has collected, newest first, with paymentHash, resource, amountSats, and paidAt. This is your feed, not a settlement record — see the next section.
  • A l402.challenge.paid webhook, once you point CallbackUrl at your own server (the skill can set this too, if you gave it a URL — otherwise set it yourself at Dashboard → Settings → Webhooks or via PUT /api/merchant/webhook-url). Fires the first time each challenge is proven paid, HMAC-signed the same way as every other Lightning Enable webhook.

Custody and fees​

Lightning Enable does not hold funds. Every sat your endpoint earns settles directly with your wallet — your own NWC wallet facilitates custody and settlement on that lane, or your chosen payment provider (Strike or OpenNode) does if you configured one of those instead. Lightning Enable never sits in the money's path; it mints the invoice, verifies the proof of payment, and gets out of the way.

There is no per-transaction fee from Lightning Enable on any plan. Your wallet or payment provider may apply its own routing or processing fee — check their fee schedule, not ours.

Selling requires a producer account: the Fast Lane trial or the Free Producer Sandbox described below.

Trial, then the Free Producer Sandbox​

If you activated with the Fast Lane, you're on a 30-day Agentic Commerce trial: unlimited endpoints, no volume cap on challenges, no per-challenge price ceiling. Everything above works at any scale during the trial.

When the trial ends without billing added, your account automatically moves to the Free Producer Sandbox — you keep the account and every endpoint you built, but three caps now apply: 3 endpoints (distinct resource paths, counted for the life of the account, never resets), 200 challenges/month, and 1,000 sats max per challenge. Add billing (Agentic Commerce, $49/month) at any point to remove the caps without losing anything you've built. Nothing above changes if you start directly on the Sandbox instead of the trial — the same skill and the same tool calls work; add_endpoint and create simply start refusing once you hit a cap, with a 402 naming which one.

Troubleshooting​

"The wallet did not answer within 30s." This is an NWC timeout, and it can surface at two different points: during configure_receive (your receive wallet didn't respond to the connection check) or during the agent's own self-test payment in step 7 (its paying wallet, if also NWC, didn't respond). Check the connection is still listed in the wallet app and that it grants make_invoice and lookup_invoice; see Nostr Wallet Connect setup — Troubleshooting for the full list of NWC failure modes.

The self-test payment fails when the receiving and paying wallets are the same node. If you pointed both configure_receive and the agent's own wallet (setup_wallet) at the same underlying Lightning node or NWC wallet, the self-test payment in step 7 can fail — most Lightning implementations refuse to route a payment back to the node that issued the invoice, since there's no real path to route through. This isn't a Lightning Enable restriction; it's how Lightning payment routing works. Use two different wallets — the receive side can stay whatever you chose, but give the agent a second, separate small wallet to pay from. This is exactly the setup already recommended in Run L402 Anywhere: Hermes + NWC and First success after activation — a dedicated small paying wallet, kept separate from anything that receives.

500 "Payment configuration error" on the first 402. This is different from the clean 400 payment_provider_not_configured refusal (see the Producer API Reference), which means no credential at all is on file. A 500 with "Payment configuration error" means a credential is on file but isn't usable — confirmed causes: a placeholder/invalid API key saved for Strike or OpenNode, or an NWC wallet that never answers the invoice request (NWC_NO_RESPONSE, including a wallet that's offline or requires an encryption scheme Lightning Enable doesn't speak — see NIP-04 requirement). Fix it with configure_receive (re-save a real credential) and, if the agent's own wallet is the one that's unusable, setup_wallet — then retry. Run l402_producer(action="status") (or GET /api/merchant/quickstart by hand) afterward to confirm the lane is actually live before minting again.

Do it by hand (raw REST)​

Everything above is the same handful of HTTP calls the skill makes for you. Useful if you're integrating from a language without the skill, or want to see exactly what's happening. All calls need X-API-Key: $LIGHTNING_ENABLE_API_KEY.

1. Configure the receive lane (NWC shown; swap for strike-key/opennode-key if using a provider):

curl -X PUT https://api.lightningenable.com/api/merchant/nwc-connection \
  -H "X-API-Key: $LIGHTNING_ENABLE_API_KEY" -H "Content-Type: application/json" \
  -d '{"nwcConnectionString": "nostr+walletconnect://<wallet-pubkey>?relay=wss://<relay-host>&secret=<secret>"}'

curl -X PUT https://api.lightningenable.com/api/merchant/payment-provider \
  -H "X-API-Key: $LIGHTNING_ENABLE_API_KEY" -H "Content-Type: application/json" \
  -d '{"provider": "nwc"}'

2. Check status:

curl https://api.lightningenable.com/api/merchant/quickstart \
  -H "X-API-Key: $LIGHTNING_ENABLE_API_KEY"

3. Create the proxy:

curl -X POST https://api.lightningenable.com/api/proxy \
  -H "X-API-Key: $LIGHTNING_ENABLE_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "name": "Forecast API",
    "targetBaseUrl": "https://api.mycompany.com",
    "defaultPriceSats": 25,
    "description": "7-day forecast, priced per call"
  }'

Note the proxyId in the response (e.g. forecast-api-a1b2) — every call below uses it.

4. Add the endpoint to the manifest:

curl -X POST https://api.lightningenable.com/api/proxy/forecast-api-a1b2/manifest/endpoints \
  -H "X-API-Key: $LIGHTNING_ENABLE_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "endpointId": "forecast",
    "path": "/v1/forecast",
    "httpMethod": "GET",
    "summary": "7-day forecast",
    "basePriceSats": 25
  }'

Keep this price in agreement with the proxy's defaultPriceSats (or any per-path pricing rule) — a mismatch shows up as a "Sync" warning in the dashboard; see Step 5 of the proxy walkthrough if you ever set them differently on purpose.

5. Publish (enable the manifest, optionally list in the registry):

curl -X PUT https://api.lightningenable.com/api/proxy/forecast-api-a1b2/manifest/settings \
  -H "X-API-Key: $LIGHTNING_ENABLE_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "manifestEnabled": true,
    "serviceDescription": "7-day weather forecasts, priced per call.",
    "manifestPubliclyListed": true
  }'

6. (Optional) Point the payment webhook at your own server:

curl -X PUT https://api.lightningenable.com/api/merchant/webhook-url \
  -H "X-API-Key: $LIGHTNING_ENABLE_API_KEY" -H "Content-Type: application/json" \
  -d '{"webhookUrl": "https://your-server.example.com/webhooks/lightning-enable"}'

7–8. Mint and pay a self-test challenge (or ask a real caller to — the endpoint is live once step 5 completes):

curl -X POST https://api.lightningenable.com/api/l402/challenges \
  -H "X-API-Key: $LIGHTNING_ENABLE_API_KEY" -H "Content-Type: application/json" \
  -H "Idempotency-Key: self-test-1" \
  -d '{"resource": "/v1/forecast", "priceSats": 25, "description": "Self-test"}'

Pay the returned invoice with any Lightning wallet that surfaces a preimage.

9. Verify:

curl -X POST https://api.lightningenable.com/api/l402/challenges/verify \
  -H "X-API-Key: $LIGHTNING_ENABLE_API_KEY" -H "Content-Type: application/json" \
  -d '{"macaroon": "<from step 7>", "preimage": "<from paying the invoice>", "resource": "/v1/forecast"}'

10. List challenges:

curl "https://api.lightningenable.com/api/l402/challenges?status=paid&limit=10" \
  -H "X-API-Key: $LIGHTNING_ENABLE_API_KEY"

Full contract for every call above — request/response shapes, error codes, idempotency rules, caveat enforcement — is in the Producer API Reference and Proxy Configuration.

Next steps​

Lightning Enable is API middleware and never holds your funds. Your wallet, or your chosen payment provider (Strike or OpenNode), facilitates custody and settlement of every payment your endpoint earns.