Start a new topic

local REST API in Bridge


as I'm asking once in a year for the local REST API, I'll do it here aswell in the hope, that it become a better priority :)

I want that the very nice REST API is available just locally in my LAN

Why I want this:

- Security reasons: I want to be responsible on my own and this is only possible with a local REST API

- Availability: Sometimes, the currently available REST API in your cloud is pretty slow. I'm waiting 10 seconds for a response which is a no go. Also: when tedee shut down their services, I can trash my bridge and I'm not able to use this smart lock anymore (because I _never_ use the phone app, I just use my openhab integration and the App HTTP Shortcut which sends a request to an own build REST API which not just opens the main door, it also opens the entry door where no tedee is possible (build in electrical lock)

Please keep in mind, that the only reason why I chose Tedee over a competitor is, that before I bought it over a year ago, I got a response on my request from you, that "soon" a local API is available at the bridge. 

I was thinking about to create an "offical" openhab binding for Tedee but if this feature is not  upcoming in the next 12 months, I'll sell it and buy something from competitors which has the local API available.

Please take this also as constructive critics :) 


4 people like this idea


I understand your need, the local REST API would be useful.

1. It is not easy to prepare a secure local API on the IoT device. Other lock vendors are doing this without any or minimal layer of security and we do not want to do the same.

2. Availability. We continuously improve the performance of the backend system according to the load. The latest version released on the previous Monday should significantly improve the response time.

We do not plan to add the local REST API in near future. I am really sorry if you were misled into buying.

Before you decide to change the lock please first check:

1. Tedee Bluetooth API documentation

2. How does the competitor implement the local REST API and is it enough secure for your purpose

Thank you for your feedback, we appreciate it.

Hi Konrad,

thanks for your response. I appreciate your honest. Sadly it doesn't make it much better.

to 1: I'll have a look in the Bluetooth API in the next weeks. But I believe, I need some bluetooth device connected on a PC and then this bluetooth hardware has to be near to tedee smartlock, correct? My server is 7m away with brick wall between the lock so I'm sure, it wouldn't work (checked with the phone app if it reaches the lock without bridge just via ble)

to 2: tbh: I don't get the security question. At the bridge needs to run a webserver with https TLS certificate for encrypted traffic. That's all you need. To secure your LAN/wifi/infrastructure I am responsible for. Of course you can always search for security holes etc. but there is not much difference between a bridge, which is already included in the wireless network and receives commands from the internet or a bridge, which has a running local webserver which receives commands from the LAN.

I assume the main challenge is to implement the very good cloud REST API to a local one running on a microcontroller unit. But to be honest: I don't see any sense migrate and harmonize all these functions to a local REST API. If you are able to without much effort, of course do it. But a simple API request for opening / closing the lock would already be a good start, isn't it ? And I think, that's not too difficult (apart from testing firmware updates OTA with webserver stuff etc. which all has to be included).

What does "we do not plan in the _near_ future" means? It sounds like it will never happen. I really hope it will not be so. That it will not happen fast, I already was aware of. But a 12 month time frame I hopefully assumed it would be possible. A concrete answer on it, with a timeframe from to on the current planned roadmap would be really nice to see.

Don't get me wrong: your lock is really great. (rechargable!) battery life time compared to the size and the noise level is perfect! the internet REST API is wonderful and perfectly described via swagger. It is just the single thing, which can occurs for some people like me a huge impact on decisions.

BR Marcel

I understand Marcel's  frustration with this topic. When the lock came out "local API coming soon" was advertised by Tedee and Marcel and I are not the only customers who are "misled into buying", if you check topics regarding tedee from about a year ago in smarthome forums. For example an answert someone apperently got from Tedee support in a German forum from a year ago:

" Aktuell ist das nicht möglich. Eine lokale Bridge API hat aber gerade die höchste Priorität im  Entwicklungsteam weil es sich do viele Kunden wünschen. Für weitere Fragen stehe ich Geren zur Verfügung. Viele Grüße" Similar quotes can be found in openhub forum etc

Hence your statement: "We do not plan to add the local REST API in near future." now is very disapointing and scratches the subject of false advertisement!

Kaktus and Jitterer, the best source of information about new features is this forum. We work closely with our partner from Germany but we do not follow their forum. I can assure you that he didn't mean to mislead anyone, the topic of local API was discussed by Tedee team but other user needs as Keypad pushed it down. It doesn't mean that we will never provide a local API. This feature is still on our list but I want to make it clear that this is not our priority at the moment and we can come back to this topic in 12 months' time.

Thanks for your reply. This forum did not excist, when you advertised "local API coming soon". And this was not just by German distribution, but if I remember correctly also on your website. I just wanted to point out that we are not the only ones, who read/heard about and are waiting for it.

And yes, we - at least I - have no idea about the size of the team and the capabilities and possibilities of it. There are several items I would like to see released. As you know I am waiting on the keypad for a year now and I was first told it comes in the first half of 2021. I just hope not everything is worked on one after another, because then this would take quite some years ;)But what I do tell people and I appreciate so far: You delivered what you promised. Maybe that's why I got upset from your post, because I know an advertised feature from another smartlock company, which was never implemented.

Hello I bought this device because it was promised that there will be a local api. I live in an area where the internet connection is rather bad and that's why it is better for me if there will be a local api. When it comes to security, please let the user decide if you tick the box in the app whether he would like to use it or not.

I hope that the implementation will take place in the near future, otherwise the device is unusable for me.

thank you for your understanding.

1 person likes this

oh an just fyi @Konrad Sikorski the German Youtube Channel from Spiel und Zeug reviewed the lock as you propably know. Check out how many people just there comment that they will not use a lock in a cloud based system. Maybe you should work on this local API to push your sales, before they all end up at Nuki 3.0...

where is the local rest api.

it was announced a year ago, or even a year earlier ;)

You say that with a smiley... I think it's annoying, that features take *such a long* time. Yes, tedee dilivered features promised, but the timeframe is just way too long. I put in two tickets end of March and beginnung of April with minor, but annoying, errors. I have not even got a response on them.

1 person likes this

Yes, that's frustrating... the smiley is ironic

You write "... tedee dilivered features ..." but not the local rest api yet... or did I miss something?

No you did not miss something there. I meant the keypad for example.
For me it was also a condition to buy the product. Unfortunately, teachers words. Excuses because of security, but you could blame by a confirmation in the app. Again, please set up a local API. Thank you very much in advance.

1 person likes this

well, I was on purpose a half year silent now. I'll quote myself from my first post  

But a 12 month time frame I hopefully assumed it would be possible.

so half time over for a simple webserver secured via TLS on a MCU.

In another thread, beside the need of local REST API because for security reason, I mentioned that your cloud API doesn't response or just 30 seconds later.

This happens once in a week - still! 2 days ago I came back and the tedee lock didnt response for 1 minute. 1 minute later the door opened. guys, that's a no go. not after all the promises 2 years ago.

I won't wait 6 month longer. Start with a local REST API of about 3-4 commands as a beta. In a dev environment I can do this within a day. When doing this as a real product, < 6 months is an easy way for a beta start.

Dont let me switch over to competitors where I almost can't wait to tell my story... I absolutely understand that keypads are a market for you because for airbnb, rent houses and so on. But now, we waited long enough!

Thank you in advance for your reading. 


I agree. It seems very unprofessional that implementations take such a long time. As If just some backroom kid is coding for you (I suppose even that would be faster...) this is very disappointing for the customers.
Login or Signup to post a comment