Firstly, I apologize for the delay in allowing your post. I wasn't notified about pending posts and it seems our spam filter got quite antsy and blocked a lot of posts.
If you are referring to the planned endpoints shown the the API v3 Preview at https://download.unimus.net/api-v3-preview/ then yes, those are not all publicly available.
You can confirm what API endpoints are publicly available at http://your-unimus-ip:8085/api/v3/ui (Note, you must be logged into your Unimus Instance first)
Currently there isn't a way to bind credentials through the API. Let me check with some people and see if there might be some alternative options.
[Draft] Unimus API v3 - feedback wanted
Thanks for the clarification, that helps.Tommy.c wrote: ↑Thu Jan 08, 2026 2:30 pmFirstly, I apologize for the delay in allowing your post. I wasn't notified about pending posts and it seems our spam filter got quite antsy and blocked a lot of posts.
If you are referring to the planned endpoints shown the the API v3 Preview at https://download.unimus.net/api-v3-preview/ then yes, those are not all publicly available.
You can confirm what API endpoints are publicly available at http://your-unimus-ip:8085/api/v3/ui (Note, you must be logged into your Unimus Instance first)
Currently there isn't a way to bind credentials through the API. Let me check with some people and see if there might be some alternative options.
Do you have any rough timeline (even high-level) for when device-related endpoints and/or credential binding might be exposed via API v3?
The reason we’re asking is that we’re planning to onboard ~47,000 devices into Unimus. Some of these platforms enforce very strict lockout policies (e.g., lock after 5 failed authentication attempts), so we’re trying to avoid a situation where credentials cannot be safely bound or validated programmatically during onboarding.
Knowing whether this functionality is coming in the near term, or if we should plan around v2 limitations long-term, would help us choose the safest approach and avoid unintended lockouts across the network.
Appreciate you checking internally.
-
AlexComputerWiz
- Posts: 1
- Joined: Sat Apr 04, 2026 7:33 pm
Hi Thomas,
We recently upgraded to v2.8.0 and have been exploring the v3 API for use in our internal automation workflows. After reviewing the locally-served API documentation, it's clear that the available v3 endpoints are still fairly limited for practical network automation use cases, particularly around device and backup management operations that we rely on day-to-day.
We understand that API development involves careful design and testing, and we genuinely appreciate the work that has gone into Unimus. That said, given that this thread originated around 2021, we'd appreciate some transparency around the current roadmap. A four-to-five year timeline for a feature that's been publicly previewed is difficult to plan around, especially as our team is actively building automation frameworks where API completeness is a key dependency.
The broader context here is that the industry is moving quickly. Operators are increasingly building internal tooling, integrations, orchestration layers, and AI-assisted workflows that depend on well-documented, stable APIs. A complete v3 API would meaningfully expand what teams like ours can do with Unimus at scale, and it would strengthen the case for continued investment in the platform internally.
To be direct: if the v3 API isn't going to reach a point where it covers the core operational endpoints in a reasonable timeframe, we need to know that now. We're at a stage in our automation development where we need to make a decision about which tools we build around for the long term. Unimus is our preference, but we can't build a roadmap around an API that may or may not materialize.
Could you share a realistic timeframe for the remaining v3 endpoint buildout, or at minimum, which areas are actively being prioritized? We're not looking to be critical. We want to keep building on Unimus. But we need clarity on direction to make that commitment confidently.
We recently upgraded to v2.8.0 and have been exploring the v3 API for use in our internal automation workflows. After reviewing the locally-served API documentation, it's clear that the available v3 endpoints are still fairly limited for practical network automation use cases, particularly around device and backup management operations that we rely on day-to-day.
We understand that API development involves careful design and testing, and we genuinely appreciate the work that has gone into Unimus. That said, given that this thread originated around 2021, we'd appreciate some transparency around the current roadmap. A four-to-five year timeline for a feature that's been publicly previewed is difficult to plan around, especially as our team is actively building automation frameworks where API completeness is a key dependency.
The broader context here is that the industry is moving quickly. Operators are increasingly building internal tooling, integrations, orchestration layers, and AI-assisted workflows that depend on well-documented, stable APIs. A complete v3 API would meaningfully expand what teams like ours can do with Unimus at scale, and it would strengthen the case for continued investment in the platform internally.
To be direct: if the v3 API isn't going to reach a point where it covers the core operational endpoints in a reasonable timeframe, we need to know that now. We're at a stage in our automation development where we need to make a decision about which tools we build around for the long term. Unimus is our preference, but we can't build a roadmap around an API that may or may not materialize.
Could you share a realistic timeframe for the remaining v3 endpoint buildout, or at minimum, which areas are actively being prioritized? We're not looking to be critical. We want to keep building on Unimus. But we need clarity on direction to make that commitment confidently.
Alex,
I believe I wrote a draft response to this a while ago and then let it slip while I waited for responses from the Devs.
I appreciate your compliments and candor.
I want you to understand that I completely share your experience and feelings on the incomplete API v3.
That said, what endpoints are you waiting on specifically? I can see about pushing those specifically.
Likely, you will not be getting the full demoed API v3 in the next 6 months. Unimus has a lot of features we have added to the GUI and that is our primary focus as that's where the majority of our customer base uses Unimus.
I believe I wrote a draft response to this a while ago and then let it slip while I waited for responses from the Devs.
I appreciate your compliments and candor.
I want you to understand that I completely share your experience and feelings on the incomplete API v3.
That said, what endpoints are you waiting on specifically? I can see about pushing those specifically.
Likely, you will not be getting the full demoed API v3 in the next 6 months. Unimus has a lot of features we have added to the GUI and that is our primary focus as that's where the majority of our customer base uses Unimus.
-
edward.fingleton
- Posts: 15
- Joined: Fri Jan 08, 2021 12:27 pm
Hi Folks,
It looks like even in the ver. 2.9 release we still don't have the ability to bind credentials to devices through API. We automate the creation of devices but because we have a range of credentials in operation on the network we're now at the point where as Unimus tries the credentials in turn it's rejecting the session because of failed login attempts. This means a user has to go and set the credential manually. I know at the time of device creation which credential will be necessary so we'd like to use the APIs listed in v3 which have yet to be released.
Where do they sit on the schedule for release?
We'd require the device create API, and the bin/unbind endpoints.
Thanks,
Ed
It looks like even in the ver. 2.9 release we still don't have the ability to bind credentials to devices through API. We automate the creation of devices but because we have a range of credentials in operation on the network we're now at the point where as Unimus tries the credentials in turn it's rejecting the session because of failed login attempts. This means a user has to go and set the credential manually. I know at the time of device creation which credential will be necessary so we'd like to use the APIs listed in v3 which have yet to be released.
Where do they sit on the schedule for release?
We'd require the device create API, and the bin/unbind endpoints.
Thanks,
Ed