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! 🙏🏻

MrAnderson

 is almost always a wrong path, not a missing Store API.

, never 404, when you skip auth or send a fake key:

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 

 (and lightning perms if you use the LN node API).

{"amount":"1","checkout":{"paymentMethods":["BTC-LN"]}}

GET /api/v1/stores/{storeId}/invoices/{invoiceId}

If the demo store has no Lightning wallet, run your own BTCPay + LND/CLN/phoenixd, or a testnet instance. phoenixd's 

 is a different API if you only need a BOLT11 without BTCPay.

AskSN

BTCPAY Error

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 **404**s 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.