The flow:
GET /v1/price
→ 402 + { invoice: "lnbc3n1p...", payment_hash: "abc123" }
pay invoice (any Lightning wallet)
GET /v1/price?payment_hash=abc123
→ 200 + { price, rsi, macd, trend, ... }
The main thing I wanted to test: can L402 work as a real auth mechanism for a production API? Turns out yes — it's been live for a week on mainnet and already receiving payments from what looks like bots or automated scripts hitting multiple endpoints in sequence.
A few things I learned building this:
- phoenixd makes the Lightning side trivial. The entire payment middleware is ~60 lines of Express code. - L402 is a genuinely better model than API keys for programmatic access. No credential to leak, natural rate limiting through economics, agents can pay autonomously. - Railway blocks exchange IPs so derivatives data is estimated from price momentum rather than real funding rates. Documented but worth knowing.
Stack: Node.js/Express on Railway, phoenixd 0.7.2 on DigitalOcean.
https://satsapi.dev/docs — full docs with JS/Python/cURL examples https://satsapi.dev/health — live node status https://github.com/Aperezvigoa/satsapi — source
Happy to answer questions about the L402 implementation or the phoenixd setup.
VERY cool! This is the perfect use of micropayments that far exceeds that of traditional fiat and credit vehicles.
It's not just a payment mechanism, it's a new primitive for HTTP itself. The protocol already has a 402 status code that's been sitting unused since 1991. Lightning makes it finally usable.
The interesting implication for AI agents: they can acquire access to resources autonomously, without any human provisioning a credential. The agent just pays. That changes how you architect systems that need to consume external data or services.
Still early.. most developers haven't seen a 402 response in production before. But the primitives are all there now.