BoostBox will respond with the full, original metadata in the x-rss-payment HTTP header.
I am coding a tool I'm calling "Runway" - a Boostbox API that reads payments made to a Strike wallet.
It's visible (and usable) here - https://podnews.net/runway - though you'll need a Strike API key to use it.
While the Strike API has really nice scoping, I want to run this entirely on the client's browser, so that I'm not handling any information about user payments. The plan is to avoid any calls by the browser via my server. The plan is to use a local database to populate details about payments.
Unfortunately, even with the correct CORS in place, the x-rss-payment header isn't visible to any browser, as this page makes clear:
This makes it impossible to use this entirely client-side, and needs us to run a proxy with all the headache that may bring.
One alternative would be to just return the JSON if the request uses an "Accept: application/json" header, which is easy to set in a browser request.
I appreciate this is a breaking change, but I think it still does what you were hoping - humanly-readable data for a human using a web-browser ("Accept: text/html") but just returning the JSON if requested the correct way.
I'd appreciate thoughts. Please do mail me directly if you'd like a Strike API key with some useful data, so you can see the thing working. I'm james@crid.land
//j
I am coding a tool I'm calling "Runway" - a Boostbox API that reads payments made to a Strike wallet.
It's visible (and usable) here - https://podnews.net/runway - though you'll need a Strike API key to use it.
While the Strike API has really nice scoping, I want to run this entirely on the client's browser, so that I'm not handling any information about user payments. The plan is to avoid any calls by the browser via my server. The plan is to use a local database to populate details about payments.
Unfortunately, even with the correct CORS in place, the x-rss-payment header isn't visible to any browser, as this page makes clear:
This makes it impossible to use this entirely client-side, and needs us to run a proxy with all the headache that may bring.
One alternative would be to just return the JSON if the request uses an "Accept: application/json" header, which is easy to set in a browser request.
I appreciate this is a breaking change, but I think it still does what you were hoping - humanly-readable data for a human using a web-browser ("Accept: text/html") but just returning the JSON if requested the correct way.
I'd appreciate thoughts. Please do mail me directly if you'd like a Strike API key with some useful data, so you can see the thing working. I'm james@crid.land
//j