📝 New article: "L402 API Design Patterns: Selling Services for Sats"

How to structure an HTTP API that accepts Lightning micropayments via L402, including token design, rate limiting, and real-world tradeoffs.

quoting
naddr1qv…lyaf

L402 API Design Patterns: Selling Services for Sats

What L402 Is

L402 is an authentication scheme built on HTTP 402 ("Payment Required") and Lightning Network invoices.

Flow: 1. Client requests a protected resource 2. Server returns 402 + a Macaroon + BOLT11 invoice 3. Client pays the invoice 4. Client presents the paid Macaroon as a Bearer token 5. Server validates Macaroon + payment preimage → grants access

No accounts. No API keys. No subscription billing. Just HTTP with money.

Pricing Tiers

Tier	Price	Access
Demo	0 sats	Single call, limited output
Basic	1000 sats	10 calls, standard models
Pro	5000 sats	100 calls, all models

The demo tier reduces friction to zero. Most users who try the demo buy the paid tier.

Rate Limiting Without Accounts

Each paid Macaroon encodes a call budget. The server decrements a counter per call. No state needed beyond a nonce check to prevent replay.

Lightning Backend Options

• LND — most mature, REST/gRPC API
• Core Lightning — lighter, plugin ecosystem
• NWC — Nostr Wallet Connect, delegate to a managed wallet

NWC via Alby is the simplest starting point: just call makeInvoice() and lookupInvoice().

Why This Pattern Works

Traditional API monetization: sign up, add credit card, wait for approval, get a key, integrate the SDK.

L402: try it → pay 1000 sats → use it immediately. The barrier is low enough that curious developers actually convert.