Open API Poll for Smart Lock

Any update on a local api.

Would be interesting in getting the Latch 5 Series but without a local API I won’t.


@Frank Please reach out to me directly. I am open to helping you all out with converting your internal/unpublished APIs to publicly documented APIs.

If you all need the resources or even the expertise I am here to help.

We can ensure we do security checks, implement rate-limiting (429s), etc.

1 Like

Yes this would be great @Frank. The only thing holding me back is a closed API… I assume I’m not alone. There are many enthusiasts that would drop whatever lock they currently have for a lock like this if they had full control as well.

1 Like

Did he reach out to you?

No, not yet. I also sent an email a few days ago, but since it’s a holiday, it might take a while to hear back. I also contacted someone managing the beta testing group for contact info for other product owners who manage the API. Fingers crossed!


Did you hear anything back yet? Really considering other locks at this point.


Nope, nothing :cry: I was really optimistic.

1 Like

Yes, we are now considering selling our 3 Ultraloqs and 2 others that we just ordered, in favor of August/Yale…

This is really disheartening b/c I don’t love their actual products as much as I do Ultraloq… but these integrations allow us to do so much with their locks…

1 Like

Even if U-tec came on here and said “Yes, we’re going to do this…” I can’t imagine how long this is going take before it would be released… esp considering it’s not even a small priority or on their backlog right now!
I think looking elsewhere is our only option! :disappointed:


Shouldn’t be difficult to just release what ever they have and use internally and let us sort it out.


It’s not that easy, unfortunately. When you build internal APIs you don’t have to think about building it to scale. Enforcing things like rate limiting to not overwhelm the server and bring down the service for everyone. I am working on moving internal APIs to make them public for the company where I work and am learning the entire process.

1 Like

The API ideally would be local, and not be reliant on the cloud. In that case rate limiting is less of an issue.

Now that you mention it. The topic is open API but not necessarily open local API. I hope they are looking at a local API as I doubt anyone is looking for a cloud API. A cloud API open or not would be useless to me as I would deem it unreliable because it’s cloud based.

Yes ideally I think consumers all want a local API. The moment your internet goes out your smart home looks pretty dumb when reliant on clouds.

OpenAPI is an API standard. So in this case it’s not open or closed API but the ask is that the API specs are written to conform to the OpenAPI 3.x standard.

At this point I don’t care if it’s a cloud or local API, I will take anything as a starting point.


Another issue with a cloud API is the moment the cloud goes out your smart home is dumb. Or the worst of all… The moment the servers are shut down because of a multitude of reasons then it’s dumb forever unless someone hacks it but that’s not something your average consumer would be able to pull off even with instructions.

For the best of both worlds for the non tech savvy users they could have an Open API for the cloud and local. That way developers of other smart home platforms can integrate either one into their platforms. While those who are tech savvy can use the platforms that prioritize local control such as home assistant.

Another plus for home assistant would be for utec to create a home assistant Bluetooth integration as home assistant can integrate with Bluetooth devices now either through Bluetooth hardware on the server or through Bluetooth proxy via esp32s. That way there’s local control over wifi and Bluetooth.

1 Like

I’m also looking for a local API as I’m using Hubitat and having local control would be ideal as the existing IFTTT integration is hit or miss at best

Sifely just opened their API.

I emailed the product manager a few months ago about it and he said they weren’t interested and now he emailed me out of nowhere to let me know they just set it up and it’s available.

So ultraloq? Bluetooth and wifi local API please?


I chose a different brand for my upgrades due to non-existent API from U-tec and requiring the ability to remote control while offline… for security reasons, it had to be accessible in a way only APi would allow. I really like U-tec… i’ve had one at my residence for 3+ years and its still going strong and much better/cost effective than the other company we went with. Alredy 6 dead after the 1st year. U-tec isn’t really into taking risks I guess. Well, I guess API must be considered a risk to them lol. Don’t make too much money, right:/ Maybe someone should tell them it’s actually a thing, literally everyone is doing it… all the cool kids:D

@Frank are you following this thread still?
Sounds like @Negron is willing to be an asset to help y’all move this along. I’d gladly chip in to help fund the development of an open API with Ulatraloq devices.

The cloud option is most interesting to us b/c we have rental homes, and also rent out some athletic courts, and training equipment… all behind different doors with Ultraloq Wi-Fi locks. Opening up direct integrations with other common apps or ideally trigger/action webhooks that could allow us to provision a new code when we get a new booking, and allow us to also set the time the code is available, when it expires, etc. and also be able to push access trigger data… “code was used” and then we could push that data to other applications easily, via Zapier, Make/Integromat, Pabbly Connect, Integrately, etc.

This could open up some completely new streams of revenue and lines of business for U-tec!

Just one example… There are over 150 million users worldwide, on Airbnb. I don’t know how many property/listings that is, but imagine the marketing campaign that you could do to target Airbnb hosts, showing them how your affordable, automated locks does all the work for creating new codes for new guests, automatically emailing them, and then deactivating the code at the end of their stay.

This is just one example. But my point is… Well it seems like there are just a few passionate people on this thread who are interested in this feature, the reality is that if you are smart about it, U-Tec could really blow up there Sales, with strategic marketing campaigns based on what this new feature would allow!


100% agreement. The ability for the community to expand on these use cases and drill into specific needs would be a game-changer. I was just thinking this morning how I’d like to be able to build a service that automatically connects AirBnB reservations to temp users. Would be amazing, but not likely something u-tec would take oin directly.

Any update on this? did Ultraloq came with any REST api solution or documentation?