Strike API vs ln.bot: Lightning Developer API Comparison

Strike is probably the most recognized name in Lightning. The app, the conference keynotes, the El Salvador rollout, the Twitter Tips integration — massive brand. And the API behind it is real infrastructure: instant global payments, fiat conversion, OAuth for third-party apps, SOC2 compliance.

But the Strike API is built around Strike user accounts. Every payment flows through a verified identity. Every entity that touches money needs KYC. This is exactly right for consumer fintech — it's what enables the fiat rails, the bank payouts, the regulatory standing. It's a hard constraint when you need programmatic wallets for bots, agents, or multi-tenant platforms where the "users" aren't humans with ID documents.

If you're building a consumer app where users have identities and you want fiat settlement — Strike API is strong. If you need wallets that code controls without signup flows — different tool.

What Strike API does well

Strike is serious infrastructure — $22.5M raised from Tim Draper and Twitter Ventures, with real products shipping to real users across 95+ countries.

The fiat bridge is the standout feature. Accept Lightning payments, settle in USD, EUR, GBP, or AUD to your bank account via ACH, wire, or SEPA. No other Lightning API does this as cleanly. Send Globally extends this to cross-border remittances — Lightning rails to Africa (Nigeria, Kenya, Ghana, and others), the Philippines, Mexico, and Vietnam, with recipients getting local currency.

OAuth Connect lets third-party apps transact on behalf of Strike users with their permission, which opens up marketplace and tipping platform models. On the compliance side: SOC2, MSB license, FinCEN registration — the kind of stuff enterprise procurement teams want to see before signing a contract.

Strike charges no per-transaction fee on Lightning. The revenue comes from a ~0.65% spread on BTC/fiat conversions.

The KYC constraint

This deserves its own section because it's the fundamental fork between the two APIs.

Strike API transactions flow through Strike user accounts. To receive payments, you direct them to a Strike user. To send payments, you spend from a Strike user's balance. This means:

• Every entity that sends or receives money needs a Strike account
• Every account requires identity verification (KYC)
• Strike isn't available everywhere — 95+ countries is broad, but it excludes New York and some other regions
• AI agents, bots, and automated systems can't create their own Strike accounts
• Multi-tenant platforms where tenants aren't KYC'd individuals hit friction

None of this is accidental. You can't settle to a bank account without knowing who owns it. You can't get SOC2 without identity controls. KYC is the price of fiat rails. Whether that's a feature or a constraint depends entirely on what you're building.

Where the paths diverge

When to choose Strike API

• You need fiat settlement — accept Bitcoin, receive dollars/euros in your bank
• You're building a consumer app where users have identities
• You need OAuth to act on behalf of users (marketplace or platform model)
• You need regulatory compliance (SOC2, MSB) for enterprise customers
• You're building cross-border remittances into Send Globally corridors
• You want the Strike brand and user base as distribution

When to choose ln.bot

• You need programmatic wallets without user signup flows
• You're building AI agent infrastructure — agents can't do KYC
• You need L402 paywalled APIs — Strike has no L402 support
• You're building for global access without geographic restrictions
• You need multi-tenant wallets where tenants aren't individuals (bots, services, game characters)
• You want to stay Bitcoin-native without touching fiat
• You need published SDK packages on npm, PyPI, crates.io, NuGet, pkg.go.dev

Code comparison

Creating an invoice — the one thing both APIs do:

Strike:

curl -X POST https://api.strike.me/v1/invoices \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "description": "Payment for service",
    "amount": {
      "currency": "USD",
      "amount": "1.50"
    }
  }'
# Then generate a quote to get the BOLT11 invoice
curl -X POST https://api.strike.me/v1/invoices/<ID>/quote \
  -H "Authorization: Bearer <API_KEY>"

ln.bot:

from lnbot import LnBot

ln = LnBot(api_key="key_...")
invoice = ln.invoices.create(amount=1000, memo="Payment for service")
# invoice.bolt11 → ready to share

Strike thinks in fiat amounts and two-step flows (create invoice, then generate quote to get the BOLT11). ln.bot thinks in sats and gives you the invoice in one call. Different mental models for different problems.

What ln.bot does that Strike can't:

# Spin up a wallet for an agent — no signup, no KYC
wallet = ln.wallets.create(name="research-agent")

# Agent pays another agent's Lightning address
ln.payments.create(target="data-agent@ln.bot", amount=500)

# Gate your API behind L402 — charge per request
from lnbot_l402 import l402
app.use("/api/data", l402.paywall(ln, price=10))

Can you use both?

Yes. A platform could use Strike API for user-facing fiat on/off-ramp — users buy Bitcoin through the Strike widget, cash out to their bank — while using ln.bot for backend wallet operations: L402 paywalls, agent wallets, programmatic treasury. Different layers, same Lightning Network underneath.

Getting started

npm install @lnbot/sdk

Full setup in the quickstart guide. SDKs for five languages.

The short version

Strike bridges Bitcoin to traditional finance — if your users have bank accounts and you need dollars at the end of the day, it's built for that. ln.bot stays on the Bitcoin side — if your "users" are software and you need wallets created at runtime, it's built for that. Pick based on what your project actually needs. Or use both — they sit at different layers and don't step on each other.