Strike API
Strike API is not a Nostr client and not the Strike consumer app. It is a payments API for cash, bitcoin and Lightning flows, with a small experimental bridge that can expose selected Strike API actions as Nostr Wallet Connect.
Strike API is payment infrastructure
Strike API is easiest to understand as a business and developer payments interface, not as a Nostr product. Strike's own documentation describes it as a way to make programmatic bitcoin and cash transactions using the Bitcoin and Lightning Networks. That includes sending, receiving, exchanging, directing payments, cash payouts to bank accounts and OAuth-based third-party integrations.
For a Nostr reader, the important distinction is simple. Strike API is not the Strike mobile app, not a social client, not a relay, not a signer and not a self-hosted Lightning node. It is a regulated payments API tied to Strike accounts. You access it with credentials, scopes, endpoint calls and webhooks. The money path runs through Strike's account and compliance model.
That makes it different from LND, CLN, LDK or phoenixd. Those are node or wallet infrastructure projects that can be run as part of a self-custodial stack. Strike API is closer to a payments provider interface that can move between cash balances, bitcoin balances, Lightning invoices, on-chain addresses and bank payout rails where the account is eligible.
The reason it appears in the Nostr Wallet Connect world is not because Strike API itself speaks Nostr. The connection comes from a small bridge called `strike-nwc-service`. That bridge listens on a Nostr relay, accepts selected NWC requests from an authorized client and calls Strike API endpoints behind the scenes.
The official API surface is broad
Strike's API reference is organized around accounts, balances, currency exchange, deposits, events, invoices, payment methods, payments, payout originators, payouts, rates, receive requests and subscriptions. The API reference version checked was `v1`, and the documentation says breaking changes will be represented by a new version while non-breaking changes are additive.
The core technical shape is conventional REST. The introduction says the API is HTTP-based, uses predictable resource-oriented URLs, accepts JSON request bodies, returns JSON responses, and uses standard HTTP response codes, authentication and verbs. That matters because developers can integrate it with normal server tooling rather than Lightning-specific daemon clients.
The API can create invoices, quote invoices, create payment quotes, execute payment quotes, read balances, manage webhook subscriptions and retrieve payment or invoice state. For payment products, those are the primitives that become checkout screens, payout workflows, paywalls, Lightning Address flows, accounting reports and notification handlers.
The breadth is also a warning. You should not treat every Strike endpoint as an NWC method waiting to happen. NWC is a wallet-connection protocol with a specific command set. Strike API is a broader payments platform. A bridge has to decide which capabilities are safe, useful and semantically compatible with NIP-47.
Accounts and verification shape the product
Before you use Strike API, you need a Strike account. The account-creation documentation separates personal users from businesses. Individuals can create a Strike account through the mobile app in supported regions, while business or organizational use requires business onboarding through Strike Dashboard.
That business process is not incidental. The documentation says business verification can include business information, documents, owner and operator identity verification, and a description of the intended API use case. Once approved, the business account can use the Dashboard and API-key features that make programmatic integration possible.
For Nostr builders, this means Strike API is not the same kind of primitive as a local node. If a hobby app can spin up a local daemon in minutes, a Strike API production use may depend on account eligibility, region support, verification, scopes and business approval. That can be exactly what a regulated merchant needs, but it is not permissionless infrastructure.
A reader evaluating this path should ask a practical question first: whose Strike account is behind the integration? If it is your own account, you still need scope discipline and operational security. If it is somebody else's service, then the custody, compliance, transaction visibility and service reliability belong to that operator.
Authentication is powerful and sensitive
Strike API supports two authentication shapes. API keys are used to access your own Strike account, do not expire and are generated from Strike Dashboard. Access tokens are used for delegated access when a Strike user authorizes a third-party application through OAuth. Both are bearer-style credentials that must be protected.
The API-key overview is explicit about scope assignment. A key can be named, described and given only the scopes needed for the operations it must perform. Each endpoint has a required scope, and a key without that scope cannot execute the endpoint. This is a useful safety boundary for payment integrations.
The same page is equally clear about risk: API keys never expire and can perform financial transactions. They should not be shared publicly, committed to source code or left in logs. If a key is compromised, it must be revoked and replaced from Dashboard. A Nostr bridge makes this even more important because a relay-facing service can become a spending interface.
If you run a Strike-backed NWC bridge, do not give it a broad key just because testing is easier. A bridge that only pays Lightning invoices needs different scopes from a merchant system that creates invoices, reads invoices, manages webhooks and triggers payouts. Minimum scopes are not a compliance nicety; they are a direct limit on blast radius.
OAuth is for delegated Strike access
Strike OAuth Connect lets a third-party app authenticate Strike users and call the Strike API on their behalf after authorization. The docs describe Strike as an OpenID Connect provider and explain that an app can use API endpoints with an obtained access token, provided the registered client and the user grant the needed permissions.
That is a different model from a single backend API key. With OAuth, the app is not merely using its own Strike account; it can act for a user who has granted access. That is valuable for marketplace, creator, payroll, dashboard or finance products where users want their own Strike account connected to another app.
It is also a heavier product and compliance path. The docs say client registration requires a Strike business account, requested API scopes, clear business use case, client secret and redirect URLs. For many Nostr experiments, that is more infrastructure than needed. For serious business integrations, it may be the right boundary.
OAuth does not automatically make a Nostr connection safer. It changes who authorizes the Strike side. The NWC side still needs unique connection secrets, relay selection, spending limits, method filtering and revocation. A robust system has to respect both permission systems rather than letting one hide the other.
Receiving payments has two paths
Strike's receive-request walkthrough explains that receive requests can return a BOLT11 Lightning invoice, an on-chain Bitcoin address or both. The request can include an amount and target currency, or omit the amount so the payer chooses what to send. When payment arrives, the application is responsible for reacting to the amount and status.
This is useful for commerce because it lets a server generate something the payer can scan or copy. A Lightning wallet can pay the BOLT11 invoice. An on-chain wallet can pay the address. A Strike user in the same currency region may settle through a direct Strike-to-Strike path rather than a public Lightning route.
Nostr apps care because many paid actions begin as invoice creation. A creator page, gated link, bot command, live chat action or paid download may need an invoice, a QR code and a webhook-confirmed state change. Strike API can provide that payment request surface, but the app still has to decide what gets unlocked and when.
A careful implementation should not assume that every receive request is settled just because it exists. The docs say the application must evaluate payment amount and status. For Nostr, that means a paid event should be linked to a stable invoice or payment identifier, and repeated webhook notifications should not unlock or credit something twice.
Sending payments is quote based
Strike's sending flow begins with a destination: a BOLT11 Lightning invoice, a Lightning Address, an LNURL target or an on-chain Bitcoin address. Before payment execution, the API creates a quote. The quote contains the amount, fees, expiration and any conversion information needed for the payment.
For Lightning invoice payments, the API uses `POST /v1/payment-quotes/lightning`. The endpoint requires the `partner.payment-quote.lightning.create` scope and accepts an `idempotency-key` header to prevent duplicate quote creation. Amountless invoices require an amount object, while fixed-amount invoices must not include one.
After the quote is created, the caller executes it. The payment object returned from execution has its own payment ID and state. The docs note that both Lightning invoices and quotes can expire; if the invoice expires, you need a new invoice, while an expired quote can be regenerated if the original invoice is still valid.
This quote-and-execute model matters when translating to NWC. A NWC client sends `pay_invoice` and expects a payment result or error. A Strike-backed wallet service has to create a quote, handle quote expiry, execute the quote, inspect the payment response and report a NIP-47-shaped result without leaking provider-specific confusion to the client.
Currency conversion is part of the offer
One of Strike API's main promises is asset flexibility. A payment can be sourced from cash or bitcoin balances where the account supports it. The developer page describes programmatic execution between USD and bitcoin, while the docs list supported currency values such as BTC, USD, EUR, USDT, GBP and AUD in several endpoints.
This is attractive for businesses that want Lightning rails without holding bitcoin for every accounting flow. A merchant can price in a local currency, receive over Lightning and have conversion happen through Strike's account model. A payout product can receive bitcoin payments and, where eligible, move cash to a bank account.
For Nostr, this cuts two ways. It can make Lightning-backed paid actions more palatable for businesses that account in cash. It also means users should not assume that a Strike-backed NWC connection is a normal Lightning node balance. It may be spending from a cash balance, a bitcoin balance or a provider account with conversion rules.
A user-facing app should avoid vague wording. If a Nostr client says a payment came from your wallet, but the backend is actually a Strike account converting cash to pay a Lightning invoice, the user deserves to know the operational reality. The payment can still be useful; it is just not the same custody or accounting model as a self-hosted node.
Webhooks are mandatory for serious flows
Strike API uses webhooks to notify applications when certain events occur. The webhook overview describes HTTP callbacks with JSON payloads. The setup page says the application should create a webhook endpoint, subscribe to event types, verify signatures and respond quickly with a `2xx` status.
The webhook payload is intentionally lightweight. The docs explain that a webhook notifies that the trigger event occurred, but does not contain all the underlying data. The application then retrieves the relevant entity from the API. That pattern is healthy because it makes webhooks a prompt to fetch state, not the whole source of truth.
Signature verification is not optional in a payment system. Strike signs each webhook with an HMAC SHA-256 signature in the `X-Webhook-Signature` header, using the secret configured on the subscription. A receiver should compute the expected HMAC over the payload and compare it safely before trusting the callback.
For a Nostr service, webhooks and relay events need separate accounting. A paid Nostr action may have a payment state in Strike, a bridge response over a relay and a content or access state in the app. These systems can fail independently. A good implementation treats webhooks as idempotent and makes repeated delivery harmless.
Rate limits and maintenance are real constraints
Strike documents rate limits by operation. The production limits checked included 250 requests per minute for invoice creation, invoice quote generation, BTC price rates, payment quote creation and payment quote execution, plus 1,000 requests per 10 minutes for other operations. Sandbox limits were lower.
When an IP exceeds a request limit, the API returns HTTP 429 with a `retry-after` header. That behavior belongs in any Nostr bridge that polls, retries or serves many app clients. A naive bridge that retries immediately on failure can turn one temporary problem into a rate-limit spiral.
Maintenance is another operational boundary. Strike's maintenance page says the API can enter maintenance mode and respond to all requests with HTTP 503 Service Unavailable. The status page exposes components for Strike API, OAuth Connect, Lightning payments, banking services, on-chain payments, withdrawals and other systems.
This is one of the main differences between provider API infrastructure and a local daemon. With a local daemon you own uptime and maintenance. With Strike API you inherit a provider's availability profile, status page, rate limits and maintenance windows. That may be fine, but it should be designed into user messaging and retry behavior.
Sandbox testing is useful but not identical
Strike provides a sandbox environment with a sandbox dashboard, sandbox auth provider, sandbox API and sandbox API reference. The sandbox uses simulated cash balances and testnet bitcoin, so developers can test transactions without real value. The documentation says code can be redeployed into production after testing.
Sandbox access still requires setup. The docs say developers should contact Strike business support, create sandbox API keys, assign scopes and use sandbox endpoints. The sandbox also has lower rate limits than production, which means load behavior cannot be assumed from small functional tests.
For Lightning-specific work, the sandbox caveat is important. The docs say testnet Lightning transactions may have different success and failure rates because testnet channel availability and liquidity differ from the real network. This matters when you are testing a Nostr Wallet Connect experience that should feel quick and reliable.
A sensible test plan uses sandbox for authorization, request formatting, webhooks, error handling and state transitions, then uses small real payments in production for final Lightning behavior. Do not launch a Strike-backed NWC service after only proving that a sandbox invoice can be created.
The Nostr bridge is experimental
The concrete Nostr connection is `SamSamskies/strike-nwc-service`, a small MIT-licensed JavaScript project described as a Nostr Wallet Connect service using Strike API. GitHub metadata checked on June 13, 2026 showed 9 stars, 3 forks, 0 open issues, creation on May 8, 2024, last push on May 19, 2024, `main` as the default branch and no published releases.
The README lists three supported NWC commands. `pay_invoice` requires Strike scopes for creating and executing Lightning payment quotes. `make_invoice` requires invoice creation and invoice quote generation scopes. `lookup_invoice` requires invoice read scope. That is a narrow bridge, not a full Strike API wrapper.
The package file shows a simple Node service using `axios`, `big.js`, `dotenv`, `light-bolt11-decoder`, `nostr-tools` and `ws`. The `.env.example` asks for a Strike API key, source currency, NWC service private key, relay URI, authorized pubkey, connection secret and maximum send amount in sats.
The project is useful because it proves the mapping can work. It should still be treated as experimental infrastructure. There are no releases, no visible test suite in the package scripts, and the code is small enough that an operator should read all of it before putting real money behind it.
How the bridge maps NWC to Strike
The bridge connects to the configured relay, subscribes to NWC wallet request events from the connection pubkey and decrypts request content. It then checks the request method. `pay_invoice` calls the Strike payment quote flow. `make_invoice` creates a Strike invoice, creates a quote for it and returns an incoming NWC result. `lookup_invoice` checks cached invoice metadata and asks Strike for the invoice state.
The `strike.js` file shows the provider mapping clearly. Paying an invoice creates a Strike Lightning payment quote at `https://api.strike.me/v1/payment-quotes/lightning`, then executes it through `payment-quotes/{id}/execute`. Making an invoice posts to `/v1/invoices`, then posts to `/v1/invoices/{invoiceId}/quote` to get a BOLT11 invoice.
The service includes a maximum send amount in sats, defaulting to 10,000 if no environment variable is set. It decodes BOLT11 invoices to estimate the amount and tracks total sent while the process is running. That is better than no budget, but it is not a persistent quota system. Restarting the service resets in-memory totals.
There are also semantic gaps. The sample `pay_invoice` handler returns a placeholder preimage string rather than a real preimage from Strike. `lookup_invoice` depends on cached invoice results instead of a general payment-hash lookup. Unsupported NWC methods return `NOT_IMPLEMENTED`. Readers should see this as a reference bridge, not a production wallet service without review.
NIP-47 defines the contract
NIP-47 describes how a client can access a remote Lightning wallet through a standardized Nostr protocol. It defines client, user and wallet service roles. The wallet service is the always-on software that has access to the wallet APIs it serves. That definition fits `strike-nwc-service`: it has access to Strike API and speaks Nostr to clients.
The protocol uses request events, response events, optional notification events and a connection URI. NIP-47 recommends unique keys per connection and budgets or constraints where possible. The relay sees event kinds and tags, but encrypted payload content is not meant to be readable by the relay.
The bridge's printed connection string follows the NWC URI pattern: `nostr+walletconnect://` plus the service public key, relay query parameter and connection secret. A Nostr client can paste that string into an app such as Damus or another NWC-capable client to send wallet requests to the service.
The protocol contract is larger than the bridge's implementation. NIP-47 includes commands such as `get_balance`, `get_info`, `list_transactions`, `pay_keysend` and hold-invoice methods. The Strike bridge supports only a subset. A client should discover or assume capability carefully and handle `NOT_IMPLEMENTED` responses gracefully.
The custody model is not self-hosted Lightning
A Strike-backed NWC service can feel like a wallet connection because the client sends NWC requests and receives NWC responses. That does not make it the same custody model as Alby Hub with a self-hosted backend, Zeus with an embedded node, CLN with an NWC plugin or a phoenixd deployment under your control.
The Strike account is the financial account. The API key or OAuth token is the authorization path. The bridge is a process that can spend through that account according to its configured scopes and code. The NWC connection secret is the app-facing permission material. Those are three separate trust surfaces.
This model may be exactly what some users want. A business can use a regulated provider, cash accounting, Lightning interoperability and webhooks without running a Lightning node. A creator can test Nostr payments from a familiar Strike balance. A developer can prototype quickly.
The model is wrong for someone seeking full self-custody, full node autonomy or a wallet service whose operator cannot see account activity. A user should not be told that NWC proves self-custody. NWC proves a communication protocol. The backend decides the custody and visibility reality.
Security review should start with secrets
The bridge needs several secrets: `STRIKE_API_KEY`, `NWC_SERVICE_PRIVKEY`, `NWC_CONNECTION_SECRET` and any host or process-manager secrets used to run the service. The Strike key can perform financial actions. The NWC connection secret lets a client sign and encrypt wallet requests. Both deserve careful handling.
Do not commit `.env` files. Do not paste NWC secrets into public notes. Do not run the service on a host where unrelated users can read process environment variables. Do not share a single connection secret across many apps unless you are comfortable revoking all of them together.
Relay choice is also security-adjacent. NIP-47 messages are encrypted, but relays still observe metadata: event timing, pubkeys, tags and message flow. A bridge handling private payments should choose relays deliberately, avoid leaking a user's main Nostr identity where possible and rotate connection keys when access changes.
Finally, treat the quota logic as a safety aid, not a guarantee. The sample bridge tracks total sent in memory, so it is vulnerable to reset on restart and may not reflect failed or partially handled requests perfectly. A production service should persist per-connection budgets, support revocation and record every payment attempt.
What to test before relying on it
Start with the Strike side. Confirm account eligibility, supported region, available balances, source currency, API scopes, sandbox behavior, production key handling, rate limits, webhook subscriptions and status-page monitoring. Create the narrowest API key that can perform the needed actions.
Then test the NWC side. Confirm the relay connection, authorized pubkey, connection URI, supported methods, decryption failures, unsupported methods, bad invoices, amountless invoices, expired invoices, quote expiry, insufficient balance, quota exhaustion and service restart behavior.
For receiving flows, create an invoice, pay it with a small amount, wait for webhook state, call lookup, restart the service and try lookup again. If the bridge relies on in-memory cache, that restart test will show you what disappears. For sending flows, verify the payment response and account history in Strike Dashboard.
A public service needs one more layer: user disclosure. Tell users whether funds are in Strike, which actions the NWC connection can perform, how to revoke access, whether the bridge operator can see payment history and what happens during downtime. A technically correct bridge can still be a bad product if the user misunderstands the trust model.
Where Strike API fits best
Strike API fits businesses, merchants, payout tools and developers who want regulated Bitcoin and Lightning payment rails without operating a Lightning node. It is especially attractive when cash accounting, bank payout paths, OAuth account access or provider-grade webhooks matter more than node autonomy.
In the Nostr ecosystem, it fits as an experimental backend path for NWC, not as a universal wallet replacement. It can help a Nostr app pay invoices from a Strike account or create invoices payable over Lightning. It can also teach builders how NIP-47 can wrap provider APIs, not only self-hosted nodes.
It is less suited to users who want self-custody by default, offline key control, arbitrary peer management, routing-node economics, privacy from a payment provider or a wallet service with broad NWC method coverage. Those users should compare Alby Hub, CLN plugins, LND bridges, phoenixd, LDK-based stacks or other self-hosted paths.
The final takeaway is practical: Strike API can be a strong payment rail, and the NWC bridge is a clever proof that provider APIs can speak Nostr Wallet Connect. Use it with clear eyes. Protect keys, narrow scopes, test failures, disclose custody, and do not confuse an experimental bridge with a finished wallet product.
Sources worth opening
Start with Strike's official developer documentation, API reference, account and API-key pages, webhook pages, sandbox guide and rate-limit page. Then read the NIP-47 spec and the `strike-nwc-service` repository to see what is actually bridged into Nostr Wallet Connect.
- Strike API documentation introduction
- Strike developer page
- What is the Strike API?
- Strike API reference introduction
- Strike account creation overview
- Strike API keys overview
- Strike API key authorization
- Strike OAuth Connect
- Strike sandbox guide
- Strike rate limits
- Strike maintenance mode
- Strike status page
- Strike webhooks overview
- Strike setting up webhooks
- Strike webhook signature verification
- Strike receiving payments walkthrough
- Strike sending payments walkthrough
- Strike directing payments walkthrough
- Strike making payouts walkthrough
- Strike example apps
- Strike get invoices endpoint
- Strike create Lightning payment quote endpoint
- Strike find receive request by ID endpoint
- Strike subscriptions endpoint
- SamSamskies/strike-nwc-service repository
- strike-nwc-service GitHub API metadata
- strike-nwc-service README
- strike-nwc-service package.json
- strike-nwc-service environment example
- strike-nwc-service NWC relay handler
- strike-nwc-service Strike API adapter
- strike-nwc-service constants
- strike-nwc-service NWC URI script
- strike-nwc-service secret generator
- NIP-47 Nostr Wallet Connect
- nwc.dev
- Alby NWC developer guide
- getAlby awesome-nwc
- Nostr Wallet Connect ecosystem post mentioning Strike API
- Nostr Wallet Connect discussion on Strike subreddit
- Alby introducing Nostr Wallet Connect
- Bitcoin Magazine NWC overview
