we are thinkink about coffee machine for our members (and also for us), because coffee is part of everyday life, and we want buy some machine, which can be control by command send by UART. With this we also thinking about making some sort of “light fabman” which will read the card and tell command to coffee machine that this user is allowed to make a coffee.
Is it possible to show in Fabman backend user card real ID or can it be accessible by API?
no, we deliberately don’t expose card IDs on demand – neither in the UI nor via the API.
You can sync member cards with another system by adding a webhook and listening for memberKey events. But we’ll never let anyone query a specific member’s key – for the same reason that you can’t ask for a member’s password.
But the good news is the new APIs that we’re adding for the Octoprint integration will also be perfect for what you want to do.
Simply read any card and use the new endpoint to ask Fabman whether it’s valid. It will tell you they key’s member (if known) and whether they are allowed to turn on the coffee machine.
Apart from being more secure, this has the benefit of logging whenever someone uses the coffee machine. So you can even charge for making coffee, if you want.
We understand this and we totally agree with this security precaution . We hope, that with these new APIs, we will find lot of new use of it. Octoprint and this coffe machine will be just top of the iceberg .
Can I ask if you have any ETA on this API? You know, we are really eager to play with new features which will this bring to us & all users of Fabman.
Just create a bridge API key for the coffee machine and use it to POST the keycard to the new /access endpoint. It will check whether they are allowed to make coffee and return the Member ID and other details, if the are.
First of all big thanks for releasing bridge API, I´m sure this will help users to make great stuff.
I´m newbe with API so please bear with me, if this is really stupid question.
I looked at bridge API and made test equipment in our account, which gave me API key. I used this key to authorize in LIVE API documentation page,
but I have no luck with testing bridge API.
When I tryed charging for something, it is working fine, it give me 201 response code every time, but when I try it with anything from bridge API I get 401 everytime.
I thought that API key is replacing cookie authorization, but I checked (to be sure) my browser cookie settings and I have cookies in browser for fabman.io.
I´m doing something wrong or did I missed something somewhere?
The Authorization header requires the string Bearer in front of the API key. Unfortunately, when using the authorization dialog on the Live API documentation page, you have to manually prepend Bearer to the API key.
I know that’s not very intuitive, I’m sorry. This is a limitation of the framework we’re using to generate the Live API page. We’ll try to find a way around this. Until then I’ll add a warning about this issue to the API documentation.
If you provide an API key, it takes precedence over any cookie for endpoints that support API keys. Until very recently only the bridge API supported API key authentication, but we’ve just extended this to all endpoints. So now you’ll get a “401 bad token” error if you try to access a non-bridge API with a bridge API key. You can use separate browser tabs if you want to experiment with the bridge API and other APIs at the same time.
General API key authentication is not documented yet, but you can already have a look at the new endpoints, if you’re curious. You might want to use it to replace username/password authentication building other API integrations like the Octoprint plugin.
. We hope, that with these new APIs, we will find lot of new use of it. Octoprint and this coffe machine will be just top of the iceberg 
.
.
