Single Sign-On & SCIM Provisioning

This section applies to organizations on an Enterprise or Education plan, only.

Vizzlo supports SAML 2.0 for single sign-on and SCIM 2.0 for automated user provisioning from an identity provider (IdP) such as Okta, Microsoft Entra ID (Azure AD), or OneLogin.

Both features require the organization to support managed user accounts and at least one verified domain.

Single Sign-On (SAML 2.0)

Vizzlo acts as a SAML Service Provider (SP). Configure your IdP with these values:

SettingValue
Entity ID / Audiencehttps://vizzlo.com
Assertion Consumer Service (ACS)https://vizzlo.com/sso/saml2
ACS bindingHTTP-POST

The SP signs its requests using RSA-SHA256. Both SP-initiated and IdP-initiated login are supported. Single Logout (SLO) is not supported.

On the Vizzlo side, an administrator configures the organization’s IdP by providing the IdP’s Entity ID, its signing certificate (PEM), and its sign-in URL.

Service Provider metadata

Returns the SP metadata document as XML, which some IdPs can import directly.

Route

GET https://vizzlo.com/sso/saml2

Assertion Consumer Service

The endpoint the IdP posts the SAML response to after authentication. The organization is matched by the assertion’s issuer (Entity ID), and the assertion’s signature is verified against the organization’s configured certificate.

Route

POST https://vizzlo.com/sso/saml2

Vizzlo reads the following attributes from the assertion (with common fallbacks, including Microsoft and urn:oid: claim names):

Just-in-time provisioning

When a user signs in via SAML, Vizzlo provisions the account on the fly:

  1. If a user with the assertion’s SSO ID already exists, they are logged in (and their name/email/avatar are updated if changed).
  2. Otherwise, if a managed account of the organization exists with that email address, the SSO ID is linked to it.
  3. Otherwise, a new managed user is created — but only if the email address is on one of the organization’s verified domains and a subscription seat is available.

SP-initiated sign-in

Vizzlo also offers a sign-in form that starts the SP-initiated flow. The user enters their email address; Vizzlo resolves the organization by the email’s domain and redirects the browser to the organization’s IdP sign-in URL.

Routes

GET https://vizzlo.com/sso/saml2/signin

POST https://vizzlo.com/sso/saml2/signin

User provisioning (SCIM 2.0)

Vizzlo exposes a SCIM 2.0 endpoint so your IdP can create, update, and deactivate managed user accounts automatically.

Base URL

Configure your IdP with the following SCIM base URL, where orgID is your organization’s ID:

https://vizzlo.com/sso/scim/v2/orgs/orgID“

You can perform a GET on the base URL to check connectivity; it returns Ok on success.

Authentication

The SCIM API is authenticated with an OAuth Bearer token. Use the personal API Token of an organization administrator (found in the user’s account settings under “API Token”). Send it on every request:

Authorization: Bearer <api-token>

The token’s owner must be an admin of the organization, and the organization must support managed accounts. Requests that fail these checks receive HTTP status code 403.

Note: SCIM error responses are returned as plain text (with the appropriate HTTP status code), not as the SCIM Error JSON envelope.

Service Provider configuration

Advertises the supported SCIM capabilities (patch and filtering are supported; bulk operations, password change, and ETags are not).

Route

GET …/sso/scim/v2/orgs/orgID/ServiceProviderConfig

The User resource

Vizzlo maps the SCIM User resource to a managed account as follows:

SCIM attributeVizzlo meaning
idVizzlo user ID (read-only, assigned on creation).
externalIdThe user’s identifier in your IdP (stored as the SSO ID).
userNameThe user’s email address.
displayNameThe user’s full name.
emailsArray of { "value": …, "primary": true }; the primary is used.
activeAlways reported as true (see limitations below).
metaStandard SCIM metadata (resourceType, created, lastModified, location).

Example User resource:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "abc123xyz4567",
  "externalId": "00u1a2b3c4d5",
  "userName": "jane@example.com",
  "displayName": "Jane Doe",
  "emails": [{ "value": "jane@example.com", "primary": true }],
  "active": true,
  "meta": {
    "resourceType": "User",
    "created": "2026-01-01T12:00:00Z",
    "lastModified": "2026-01-01T12:00:00Z",
    "location": "https://vizzlo.com/sso/scim/v2/orgs/abc123/Users/abc123xyz4567"
  }
}

Listing users

Returns the organization’s managed users as a SCIM ListResponse.

Route

GET …/sso/scim/v2/orgs/orgID/Users

Query parameters

The attributes and excludedAttributes parameters are not supported.

Return value
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 42,
  "itemsPerPage": 100,
  "startIndex": 1,
  "Resources": [ … ]
}

Getting a user

Route

GET …/sso/scim/v2/orgs/orgID/Users/id“

Returns the User resource, or HTTP status code 404 if no such user belongs to the organization.

Creating a user

Creates a new managed account. The request must include externalId, a primary email, and a name (via displayName, name.formatted, or userName). The email address must be on a verified domain of the organization.

Route

POST …/sso/scim/v2/orgs/orgID/Users

Return value

On success, HTTP status code 201 and the created User resource. If a subscription seat must be purchased and payment cannot be arranged, HTTP status code 402 is returned. Invalid input (missing fields, unverified domain) returns HTTP status code 400.

Replacing and updating a user

Routes

PUT …/sso/scim/v2/orgs/orgID/Users/id“

PATCH …/sso/scim/v2/orgs/orgID/Users/id“

Both return the updated User resource. Changing externalId to one already in use returns HTTP status code 400.

Deleting a user

Deprovisioning is done by deleting the user (Vizzlo does not use active: false).

Route

DELETE …/sso/scim/v2/orgs/orgID/Users/id“

Return value

No content (HTTP status code 204) upon success.

Limitations