Get the team SSO overview
const url = 'https://api.deploybase.eu/api/v1/api/v1/team/sso';const options = {method: 'GET', headers: {Authorization: '<Authorization>'}};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url https://api.deploybase.eu/api/v1/api/v1/team/sso \ --header 'Authorization: <Authorization>'Returns the redirect URI to register in the identity provider plus the team’s connections, oldest first. The redirect URI is the same for every connection and is available before any connection exists, which is the order the setup actually happens in: register the client in your IdP first, create the connection here second. Client secrets are never returned. Team admin or owner.
Authorizations
Section titled “ Authorizations ”Responses
Section titled “ Responses ”OK
object
object
object
Connections is the team’s connections, oldest first. Never null: an empty list is the normal state of a team that has not set SSO up yet.
object
JitEnabled is the admin’s decision that a sign-in through this provider may create the membership it does not find. On by default; an invite-only team turns it off.
JitRole is the role such a created member lands on: member or viewer, never more.
LastLoginAt is the last successful sign-in through this connection, or nil when there has never been one. The settings page turns nil into “No one has signed in yet” — the proof an admin wants before handing the link to their team — so it is a pointer rather than a zero time nothing can distinguish from 1 January year 1.
MemberCount is how many of the team’s members sign in through this connection. It is what the delete confirmation counts: those members lose their SSO link and fall back to email until they are linked again.
RedirectURI is the callback the admin must register in their own IdP. It is Zitadel’s, not ours, and it is the same for every connection — which is exactly why it rides on every view instead of living in the frontend: the value depends on which Zitadel this deployment talks to, and a hard-coded copy would be wrong on every other environment.
TrustUnverifiedEmail is the admin’s statement that this provider’s addresses may be used to match a user even when it does not report them as verified. Stored and returned in phase 1; read by phase 2 matching.
Warnings are the discovery advisories for the issuer, present only on the responses to Create and Update — the two moments the admin is looking at the form and can still act on them. A list or a get does not re-fetch the issuer.
object
RedirectURI is Zitadel’s callback, the same for every connection of every team.
Example generated
{ "data": { "connections": [ { "client_id": "example", "created_at": "example", "has_client_secret": true, "id": "example", "is_active": true, "is_id_token_mapping": true, "issuer": "example", "jit_enabled": true, "jit_role": "example", "last_login_at": "example", "member_count": 1, "name": "example", "provider": "example", "redirect_uri": "example", "scopes": [ "example" ], "trust_unverified_email": true, "updated_at": "example", "warnings": [ { "code": "example", "docs_url": "example", "message": "example" } ] } ], "redirect_uri": "example" }, "meta": { "request_id": "example", "timestamp": "example", "trace_id": "example" }}Unauthorized
object
object
Example generated
{ "code": "example", "details": "example", "error": "example", "meta": { "request_id": "example", "timestamp": "example", "trace_id": "example" }}Forbidden
object
object
Example generated
{ "code": "example", "details": "example", "error": "example", "meta": { "request_id": "example", "timestamp": "example", "trace_id": "example" }}Internal Server Error
object
object
Example generated
{ "code": "example", "details": "example", "error": "example", "meta": { "request_id": "example", "timestamp": "example", "trace_id": "example" }}Live 022265e7 built