Strong +1, with one technical clarification so the solution genuinely fits this kind of integration.

The key distinction here is the direction of the SSO. To embed Huddle into our own systems, we need Huddle in the role of Service Provider: Huddle accepts a login that has already been completed elsewhere, rather than handling the login itself. In concrete terms:

The common standards for this are SAML 2.0 and OIDC (OpenID Connect). Supporting either one would make Huddle connectable to virtually any existing login environment.

Should a full implementation be too large for the short term, a lighter interim solution would already help enormously: an API endpoint that lets us request a single-use, short-lived login link for an existing user, server to server. That covers the large majority of the convenience and is far quicker to build.

For users, this means one login and one environment. For Huddle owners, it makes the platform far easier to slot into an existing digital ecosystem.

I would strongly support adding an SSO option to allow Huddle to be seamlessly embedded into our own systems and portals.

For our users, this would mean one login, one environment, and a much smoother learning experience. No switching platforms, no extra passwords, no friction.

For organisations, it would make Huddle far easier to integrate into existing digital ecosystems such as intranets, LMS platforms, and internal dashboards. This is especially important when learning is part of daily workflows, not a separate destination.

In short: seamless access leads to higher engagement, better learning outcomes, and stronger long term customer value.