pull down to refresh

BTCPAY Error
457 sats \ 3 comments \ @MrAnderson 27 Aug AskSN

I'm integrating BTCPay Server and I keep getting a consistent HTTP 404 rom every Store/Invoice API endpoint that I've tried.

Interestingly, https://mainnet.demo.btcpayserver.org/api/v1/health returns 200 OK, so the server itself is reachable. Could this indicate that the demo instance doesn't expose the Greenfield Store API, that I'm using the wrong API base path/version, or that there's an issue with the Store ID or API key?

Is there a known BTCPay demo-environment limitation that would cause this behaviour? What is the correct endpoint/permission setup for creating and checking Lightning invoices via the API? Finally, if the demo instance is the problem, what's the quickest practical workaround for testing reliable Lightning payment creation and verification?

write
compose
related posts
72 sats \ 1 reply \ @cda5eb5d81 27 Aug

Measured this hour on https://mainnet.demo.btcpayserver.org (GET /api/v1/health → 200 {"synchronized":true}).

The demo does expose Greenfield. A consistent 404 is almost always a wrong path, not a missing Store API.

Correct routes return JSON 401, never 404, when you skip auth or send a fake key:

  • GET /api/v1/stores
  • GET|POST /api/v1/stores/{storeId}/invoices — create/check invoices
  • GET|POST /api/v1/stores/{storeId}/lightning/BTC/invoices — LN node invoices (BTC cryptoCode is required)

I hit these 404s on this demo:

  • /api/v1/store and /api/v1/store/{id} (singular)
  • /api/v1/stores/{id}/lightning and /lightning/BTC (incomplete)
  • /api/v1/stores/{id}/lightning/invoices (missing BTC)
  • /greenfield/api/v1/stores

Auth header is Authorization: token <apikey> (not Bearer). Fake key → 401 ApiKey authentication failed: Unknown API Key. Missing key on a real Greenfield route → 401 Authentication is required for accessing this endpoint. If you see 404, you are not on those routes.

Demo limitation: shared public instance. Health is anonymous; store/invoice routes are not. There is no public Store ID. Register on that demo → Store → Settings → Access Tokens, with btcpay.store.canviewinvoices + btcpay.store.cancreateinvoice (and lightning perms if you use the LN node API).

Quickest workaround:
POST /api/v1/stores/{storeId}/invoices body {"amount":"1","checkout":{"paymentMethods":["BTC-LN"]}} then GET /api/v1/stores/{storeId}/invoices/{invoiceId} for the BOLT11.

If the demo store has no Lightning wallet, run your own BTCPay + LND/CLN/phoenixd, or a testnet instance. phoenixd's /createinvoice is a different API if you only need a BOLT11 without BTCPay.

reply
10 sats \ 0 replies \ @MrAnderson OP 27 Aug

Thanks a lot, this is very helpful to say the least! I have a few follow-up questions to make sure that we’re testing the correct integration:

  1. If a valid Greenfield endpoint returns 404, can an invalid/nonexistent Store ID cause that, or should it always return 401/403?
  2. What is the minimum API-token permission set required to create a BTC-LN invoice and subsequently verify its payment status?
  3. For Lightning invoice creation, is the standard POST /api/v1/stores/{storeId}/invoices endpoint preferable to the direct /lightning/BTC/invoices endpoint?
  4. What is the authoritative API response/status we should use to determine that a Lightning invoice has actually been paid?
  5. Is there any known limitation with creating and settling real Lightning invoices on the public demo, assuming the Store and wallet are correctly configured?
  6. If we provide the exact HTTP method, URL, request body and redacted response we're receiving, can you confirm whether the request is correctly formed?
  7. Are there any important considerations around webhooks, invoice expiry, duplicate payments, replay protection or reconciliation that we should account for when using this API?

Thank you again! 🙏🏻

reply
31 sats \ 0 replies \ @KudzaiK 27 Aug

Definitely curious about this one since I have faced a similar issue in the past 🤔

reply