Skip to main content

​
Introduction

Bland supports both OIDC (OpenID Connect) and SAML 2.0 based Single Sign-On (SSO) for enterprise workspaces. This enables your users to authenticate with their existing identity provider (IdP) — such as Okta, Azure Active Directory, Google Workspace, Auth0, or any SAML 2.0 compatible provider — instead of managing separate Bland credentials. Once connected, users from your domain can log in with Sign in with SSO, and new users will be provisioned automatically into your workspace.
New: Bland now supports both OIDC and SAML protocols. Choose OIDC for simpler setup and modern authentication, or SAML for enterprise compliance and legacy system compatibility.

​
Prerequisites

Before configuring SSO, ensure you have:
  • Admin access to your Bland organization
  • Admin access to your identity provider (IdP)
  • Your organization’s verified email domain (e.g., company.com)
  • For SAML: Understanding of X.509 certificates and metadata
  • For OIDC: Ability to create OAuth 2.0 applications

​
Quick Start

1

Choose Your Protocol

OIDC - Recommended for: Okta, Azure AD, Auth0, modern IdPsSAML - Required for: Google Workspace, Microsoft ADFS, or when mandated by security policy
2

Plan Your Provider ID

Choose a unique Provider ID (e.g., company-okta or company-saml). This will be used in all your URLs. You can customize this or let Bland auto-generate it from your domain.
3

Create Provider in Bland

Navigate to Settings → SSO in Bland and add your provider configuration with your chosen Provider ID
4

Configure Your IdP

Create an application in your identity provider using the URLs generated with your Provider ID
5

Test Connection

Use the Test button in Bland to verify the configuration works

​
Okta Configuration

​
Okta OIDC Setup

  1. Sign in to Okta Admin Console
  2. Go to Applications → Applications
  3. Click Create App Integration
  4. Select OIDC - OpenID Connect as the Sign-in method
  5. Select Web Application as the Application type
  6. Click Next
General Settings:
  • App integration name: Bland SSO
  • Logo: (Optional) Upload your company logo
Grant Type:
  • ✅ Authorization Code
  • ✅ Refresh Token (recommended)
  • ❌ Implicit (not recommended)
Sign-in redirect URIs:
https://api.bland.ai/authorization/sso/callback/[provider-id]
Replace [provider-id] with your chosen Provider ID (e.g., company-okta)
Sign-out redirect URIs: (Optional)
https://app.bland.ai/logout
Controlled access:
  • Allow everyone in your organization to access (recommended for company-wide SSO)
  • Limit access to selected groups (if you want to control access)
Click Save
For role mapping:
  1. Go to Sign On tab → OpenID Connect ID Token → Edit
  2. Click Add Claim
  3. Configure:
    • Name: groups
    • Include in: ID Token, Access Token
    • Value type: Groups
    • Filter: .* (for all groups)
    • Include in: Any scope
  4. Click Create
From the Sign On tab, copy:
  • Issuer: https://[your-okta-domain].okta.com
  • Client ID: The long alphanumeric string
  • Client Secret: Click the eye icon to reveal
Okta provides automatic discovery at:
https://[your-okta-domain].okta.com/.well-known/openid-configuration
  1. Go to Settings → SSO → Add Provider
  2. Select OIDC (OpenID Connect) as Provider Type
  3. Enter:
    • Provider ID: Your chosen ID (e.g., company-okta) or leave blank to auto-generate
    • Email Domain: company.com
    • Issuer URL: From Okta (e.g., https://dev-12345.okta.com)
    • Client ID: From Okta
    • Client Secret: From Okta
  4. Optional: Configure scopes (defaults to openid email profile)
  5. Optional: Enable PKCE for enhanced security (recommended)
  6. Click Add Provider
Bland will automatically discover OIDC endpoints from the issuer URL. If auto-discovery fails, you can manually specify endpoints in the Optional Endpoints section.

​
Okta SAML Setup

  1. In Okta Admin, go to Applications → Applications
  2. Click Create App Integration
  3. Select SAML 2.0 as the Sign-in method
  4. Click Next
  5. Enter App name: Bland SSO
  6. Click Next
General:
  • Single sign-on URL: 
    https://api.bland.ai/authorization/sso/saml2/callback/[provider-id]
  • ✅ Use this for Recipient URL and Destination URL
  • Audience URI (SP Entity ID): 
    https://api.bland.ai/sp/[provider-id]
  • Name ID format: EmailAddress
  • Application username: Email
Add these attribute statements:
NameName FormatValue
emailUnspecifieduser.email
firstNameUnspecifieduser.firstName
lastNameUnspecifieduser.lastName
nameUnspecifieduser.displayName
For role mapping, add Group Attribute:
NameName FormatFilter
rolesUnspecified.*
  1. Go to Sign On tab → View SAML setup instructions
  2. Copy:
    • Identity Provider Issuer
    • Identity Provider Single Sign-On URL
    • X.509 Certificate (entire content)
  3. Or download the metadata XML
  1. Go to Settings → SSO → Add Provider
  2. Select SAML 2.0 as Provider Type
  3. Enter basic configuration:
    • Provider ID: Your chosen ID (e.g., company-okta-saml) or leave blank to auto-generate
    • Email Domain: company.com
    • Issuer URL: Identity Provider Issuer from Okta
  4. Choose configuration method: Option 1: Metadata Import (Recommended)
    • Paste the metadata XML from Okta, or
    • Provide the metadata URL (may have CORS issues locally)
    Option 2: Manual Configuration
    • Entry Point: Identity Provider Single Sign-On URL from Okta
    • X.509 Certificate: Paste the entire certificate including BEGIN/END lines
  5. Click Add Provider
  6. Download SP metadata using the “Metadata” button and upload to Okta if needed

​
Azure AD (Microsoft Entra ID)

​
Azure AD OIDC Setup

  1. Sign in to Azure Portal
  2. Go to Azure Active Directory → App registrations
  3. Click New registration
  4. Configure:
    • Name: Bland SSO
    • Supported account types: Accounts in this organizational directory only
    • Redirect URI: Web → https://api.bland.ai/authorization/sso/callback/[provider-id] (Replace [provider-id] with your chosen ID, e.g., company-azure)
  5. Click Register
  6. Copy the Application (client) ID and Directory (tenant) ID
  1. Go to Certificates & secrets → Client secrets
  2. Click New client secret
  3. Description: Bland SSO Secret
  4. Choose expiration (12-24 months recommended)
  5. Click Add
  6. IMMEDIATELY copy the secret value (won’t be shown again)
  1. Go to API permissions
  2. Click Add a permission → Microsoft Graph → Delegated permissions
  3. Add:
    • openid
    • profile
    • email
    • User.Read
  4. Click Grant admin consent for [Organization]
  1. Go to Token configuration
  2. Click Add optional claim → ID
  3. Select: email, family_name, given_name, preferred_username
  4. For role mapping, click Add groups claim:
    • Select Security groups
    • Under ID, select Group ID
  1. In Bland, go to Settings → SSO → Add Provider
  2. Select OIDC (OpenID Connect)
  3. Enter:
    • Provider ID: Your chosen ID (e.g., company-azure) or leave blank to auto-generate
    • Email Domain: company.com
    • Issuer URL: https://login.microsoftonline.com/[tenant-id]/v2.0 (Replace [tenant-id] with your Directory (tenant) ID)
    • Client ID: Application (client) ID from Azure
    • Client Secret: Secret value from Azure
  4. Optional: Configure scopes (defaults to openid email profile)
  5. Click Add Provider
Azure AD endpoints will be automatically discovered. The issuer URL must include /v2.0 for the v2.0 endpoint.

​
Azure AD SAML Setup

  1. In Azure AD, go to Enterprise applications
  2. Click New application → Create your own application
  3. Name: Bland SSO SAML
  4. Select: Integrate any other application you don’t find in the gallery
  5. Click Create
  1. Go to Single sign-on → Select SAML
  2. Edit Basic SAML Configuration:
    • Identifier (Entity ID): https://api.bland.ai/sp/[provider-id] (Replace [provider-id] with your chosen ID, e.g., company-azure-saml)
    • Reply URL: https://api.bland.ai/authorization/sso/saml2/callback/[provider-id]
    • Sign on URL: https://app.bland.ai/login
Edit User Attributes & Claims:
Claim NameSource Attribute
emailaddressuser.mail
givennameuser.givenname
surnameuser.surname
nameuser.displayname
Simplify by editing each claim name to: email, firstName, lastName, name
  1. In SAML Certificates, download Certificate (Base64)
  2. Copy Login URL and Azure AD Identifier
  1. Go to Settings → SSO → Add Provider
  2. Select SAML 2.0 as Provider Type
  3. Enter basic configuration:
    • Provider ID: Your chosen ID (e.g., company-azure-saml) or leave blank to auto-generate
    • Email Domain: company.com
    • Issuer URL: Azure AD Identifier from Step 4
  4. Choose configuration method: Option 1: Manual Configuration
    • Entry Point: Login URL from Azure
    • X.509 Certificate: Paste the downloaded certificate (Base64)
    Option 2: Metadata Import
    • Download Federation Metadata XML from Azure
    • Paste the entire XML in the IdP Metadata XML field
  5. Click Add Provider
  6. Download SP metadata using the “Metadata” button if needed by Azure

​
Azure AD Compliance & Advanced Features

Compliance Considerations:
  • Azure AD provides detailed audit logs with configurable retention
  • Use Privileged Identity Management (PIM) for just-in-time admin access
  • Enable Identity Protection for risk-based conditional access
  • Configure log retention per compliance requirements (GDPR, HIPAA, etc.)
Advanced Security:
  • Conditional Access Policies: Require MFA, restrict by location/device
  • Risk-Based Policies: Block or challenge risky sign-ins
  • Device Compliance: Require managed/compliant devices

​
Google Workspace

Google Workspace only supports SAML for third-party applications. OIDC is reserved for Google’s own services.
1

Access Admin Console

Sign in to Google Admin Console with Super Admin account
2

Add Custom SAML App

  1. Go to Apps → Web and mobile apps
  2. Click Add app → Add custom SAML app
  3. Enter:
    • App name: Bland SSO
    • App description: Single Sign-On for Bland AI
  4. Click Continue
3

Download IdP Metadata

Download or copy:
  • SSO URL
  • Entity ID
  • Certificate
  • Or download the full metadata XML
Click Continue
4

Configure Service Provider

Enter:
  • ACS URL: https://api.bland.ai/authorization/sso/saml2/callback/[provider-id] (Replace [provider-id] with your chosen ID, e.g., company-google)
  • Entity ID: https://api.bland.ai/sp/[provider-id]
  • Start URL: https://app.bland.ai/login (optional)
  • Signed response: ✅ Checked
  • Name ID format: EMAIL
  • Name ID: Basic Information > Primary email
5

Configure Attributes

Map these attributes:
Google DirectoryApp Attribute
Primary emailemail
First namefirstName
Last namelastName
Full namename
6

Configure in Bland

  1. Go to Settings → SSO → Add Provider
  2. Select SAML 2.0 as Provider Type
  3. Enter:
    • Provider ID: Your chosen ID (e.g., company-google) or leave blank to auto-generate
    • Email Domain: company.com
    • Issuer URL: Entity ID from Google
  4. Choose configuration method:
    • Option 1: Metadata Import - Paste the metadata XML from Google
    • Option 2: Manual Configuration - Enter SSO URL and Certificate
  5. Click Add Provider
  6. If you let Bland auto-generate the Provider ID, update your Google Workspace app configuration with the generated ID
  7. Enable the app for desired organizational units in Google Admin Console
7

Test Configuration

From Google Admin Console:
  • In the Bland SSO app, click Test SAML login
  • This opens the SSO flow in a new tab
From Bland:
  • Use the Test button in SSO settings
  • Or test with an incognito browser window
Google Workspace changes can take up to 24 hours to propagate, though typically activate within 15 minutes.

​
Google Workspace Security Features

Context-Aware Access:
  • Configure access levels based on device trust status, IP location, and user/group membership
Compliance and Logging:
  • Access Transparency: Logs of admin actions (Enterprise editions)
  • Data Regions: Configure data residency requirements
  • Audit Logs: Export SAML events to BigQuery for analysis
  • SIEM Integration: Connect logs to security monitoring tools
Password Security:
  • Enable password alert for compromised passwords
  • Configure strong password requirements
  • Regular rotation policies

​
Other Identity Providers

​
Auth0

  1. Create new Application → Regular Web Application
  2. Settings:
    • Allowed Callback URLs: https://api.bland.ai/authorization/sso/callback/[provider-id] (Replace [provider-id] with your chosen ID, e.g., company-auth0)
    • Allowed Web Origins: https://app.bland.ai
  3. In Bland, configure with:
    • Provider ID: Your chosen ID or leave blank to auto-generate
    • Email Domain: Your organization’s email domain
    • Issuer: https://[your-domain].auth0.com/
    • Client ID and Client Secret from Auth0
  4. Auth0 endpoints will be auto-discovered from the issuer URL
  1. Create new Application → Regular Web Application
  2. Enable SAML2 Web App addon
  3. Configure:
    • Application Callback URL: https://api.bland.ai/authorization/sso/saml2/callback/[provider-id] (Replace [provider-id] with your chosen ID)
    • Settings: Configure attribute mappings for email, firstName, lastName
  4. In Bland, add SAML provider with:
    • Provider ID: Your chosen ID or leave blank to auto-generate
    • Auth0’s metadata or manual configuration

​
Ping Identity

Both OIDC and SAML supported:
  • OIDC: Configure redirect URI with your chosen provider ID
  • SAML: Use SP Entity ID format https://api.bland.ai/sp/[provider-id]
  • Provider ID can be specified or auto-generated in Bland

​
OneLogin

Supports both protocols:
  • Create app from catalog or custom connector
  • Configure with your chosen provider ID in all endpoints
  • Download SP metadata from Bland after provider creation for SAML

​
URL Reference

​
OIDC Endpoints

EndpointURL FormatNotes
Redirect URIhttps://api.bland.ai/authorization/sso/callback/[provider-id]Replace [provider-id] with your chosen ID
DiscoveryAuto-discovery from issuer URLEndpoints fetched automatically

​
SAML Endpoints

EndpointURL FormatNotes
ACS URLhttps://api.bland.ai/authorization/sso/saml2/callback/[provider-id]Assertion Consumer Service URL
SP Entity IDhttps://api.bland.ai/sp/[provider-id]Service Provider identifier
SP MetadataGenerated after provider creationDownload from SSO settings
Provider ID: You can specify your own provider ID (e.g., company-okta, acme-azure) or leave it blank to auto-generate. Once created, the provider ID cannot be changed.

​
Troubleshooting

​
Common OIDC Issues

Cause: Redirect URI mismatchSolution:
  • Copy exact URI from Bland including provider ID
  • Check for trailing slashes or spaces
  • Ensure HTTPS is used
Cause: Wrong or expired credentialsSolution:
  • Regenerate client secret in IdP
  • Update immediately in Bland
  • Verify no extra spaces when pasting
Cause: Incorrect issuer URL formatSolution:
  • Include or remove trailing slashes as required by your IdP
  • For Azure: Use /v2.0 endpoint for v2.0 tokens
  • For Okta: Use your Okta domain (with or without /oauth2/default based on your setup)
  • Verify the issuer URL matches exactly what your IdP expects

​
Common SAML Issues

Cause: Incorrect attribute mappingSolution:
  • Set NameID format to emailAddress
  • Use “Unspecified” for attribute name format
  • Ensure email attribute is mapped
Cause: Certificate mismatchSolution:
  • Re-download certificate from IdP
  • Include full certificate with BEGIN/END lines
  • Check certificate expiration
Cause: SP Entity ID mismatchSolution:
  • Ensure Entity ID matches exactly: https://api.bland.ai/sp/[provider-id]
  • Use the same provider ID in both Bland and your IdP
  • If you auto-generated the ID, copy it from Bland to your IdP
  • Check for typos, extra spaces, or case sensitivity
Cause: Missing user attributesSolution:
  • Verify attribute mappings in IdP
  • Ensure user has email in IdP profile
  • Check attributes are being sent in response

​
Testing Your Configuration

  1. Use Test Button: In Bland SSO settings, click Test next to your provider
  2. Check Browser Console: Open Developer Tools (F12) → Network tab for detailed errors
  3. Verify in IdP: Check IdP audit logs for authentication attempts
  4. Test with Different User: Try a non-admin account to verify permissions
  5. Test in Incognito Mode: Always test in incognito/private browsing mode to avoid cached sessions

​
Advanced Debugging Tools

For SAML: For OIDC:
  • Use jwt.io to decode ID tokens
  • Verify iss (issuer), aud (audience), and claims
Network Analysis:
  • Export HAR file from browser Network tab for support

​
Debug Checklist

  • Email domain matches exactly (no www, no subdomains)
  • Provider is active in Bland settings
  • User is assigned to application in IdP
  • URLs updated with actual provider ID
  • Certificates valid and not expired (SAML)
  • Client secrets valid and not expired (OIDC)
  • Attributes properly mapped
  • Test button works successfully

​
Security Best Practices

​
Certificate & Secret Management

Critical: Set calendar reminders 30 days before certificate and secret expiration!
  • SAML Certificates:
    • Monitor expiration dates (typically 1-3 years)
    • Rotate during low-usage periods
    • Keep backup of current working certificates
  • OIDC Secrets:
    • Rotate every 6-12 months
    • Regenerate in IdP first, then update in Bland immediately
    • Never share secrets via email or chat
  • Document rotation procedures for your team
  • Test immediately after rotation with non-admin account

​
Access Control

  1. Use Groups: Manage access via IdP groups rather than individual assignments
  2. Regular Audits: Review SSO access quarterly
  3. Immediate Revocation: Remove departing employees promptly
  4. MFA Enforcement: Require multi-factor authentication in your IdP

​
Monitoring

  • Enable SSO audit logging in your IdP
  • Monitor failed authentication attempts
  • Set up alerts for unusual patterns
  • Review logs during security incidents
  • Regular Reviews:
    • Audit user access monthly
    • Review IdP logs weekly
    • Check for deprecated features quarterly

​
Platform-Specific Security Recommendations

Okta:
  • Don’t assign to “Everyone” unless intended
  • Use Okta Verify or hardware tokens for higher security
  • Review system logs for suspicious activity regularly
Azure AD:
  • Use Conditional Access for location/device restrictions
  • Enable risk-based authentication policies
  • Implement Privileged Identity Management (PIM)
Google Workspace:
  • Enable Context-Aware Access levels
  • Use Security Keys for admin accounts
  • Configure data residency requirements

​
Role Mapping & Group Inheritance

Bland automatically maps IdP groups and roles to organization permissions, enabling seamless role inheritance from your existing identity provider.

​
How It Works

When users sign in via SSO, Bland reads their group memberships from the IdP and automatically assigns the appropriate role in your organization.

​
Supported Group Mappings

Groups are mapped based on their names. The following patterns are recognized: Admin Role:
  • Bland AI - Static - Admin
  • bland-admin
  • Groups containing: admin, administrator, owner, manager, super
  • Example: IT-Admin, Super-Users, Organization-Administrators
Operator Role:
  • Bland AI - Static - Operator
  • bland-operator
  • Groups containing: operator, support
  • Example: Support-Team, Call-Operators
Viewer Role (Read-Only):
  • Bland AI - Static - Viewer
  • bland-viewer
  • Groups containing: viewer, read-only, readonly
  • Example: Read-Only-Users, Audit-Viewers
Default: Users without matching groups receive the operator role.

​
IdP-Specific Configuration

  1. Create Groups in Okta Directory → Groups:
    • Bland AI - Static - Admin
    • Bland AI - Static - Operator
    • Bland AI - Static - Viewer
  2. Assign Groups to Application:
    • Go to your Bland SSO app → Assignments
    • Assign the groups (not just users)
  3. Configure Groups Claim:
    • Go to Security → API → Authorization Servers → Your Server
    • Claims tab → Add Claim
    • Name: groups
    • Include in: ID Token
    • Value type: Groups
    • Filter: Matches regex .*
  4. Add Groups Scope (if needed):
    • Scopes tab → Add Scope
    • Name: groups
    • Display: Access to user groups
  1. Create Security Groups:
    • Azure AD → Groups → New Group
    • Type: Security
    • Names: Bland AI - Static - Admin, etc.
  2. Configure Groups Claim:
    • App Registration → Token configuration
    • Add groups claim → Security groups
    • Select: Group ID
  3. Map Group Names (Optional):
    • Enterprise App → Single sign-on → Attributes & Claims
    • Add group claim with transformation to send group names instead of IDs
For SAML with Google Workspace:
  1. Create Groups in Google Admin:
    • Groups → Create Group
    • Names: bland-admin@company.com, etc.
  2. Configure Group Attribute:
    • In SAML app configuration
    • Add attribute: groups
    • Google Directory attribute: Groups
    • Filter: Can specify specific groups or all
  1. Configure Group Claims:
    • Edit Claim Rules → Add Rule
    • Send LDAP Attributes as Claims
    • Attribute: Token-Groups - Unqualified Names
    • Outgoing Claim Type: groups
  2. Or use Role Claims:
    • Send LDAP Attributes as Claims
    • Attribute: Token-Groups - Unqualified Names
    • Outgoing Claim Type: http://schemas.microsoft.com/ws/2008/06/identity/claims/role

​
Dynamic Role Updates

  • Automatic Sync: Roles are checked and updated on each login
  • Immediate Effect: Role changes in your IdP take effect on next user login
  • No Manual Updates: Admins don’t need to manually manage user roles in Bland

​
Custom Role Mapping

For enterprise customers with specific requirements:
  • Custom Group Names: Map your existing group structure
  • Complex Rules: Combine multiple groups or attributes
  • Department-Based: Map based on department or other attributes
Contact hello@bland.ai for custom role mapping configuration.

​
Testing Role Mapping

  1. Verify Groups in Token:
    • Use browser DevTools during SSO login
    • Check Network tab for the callback request
    • For OIDC: Decode the ID token at jwt.io
    • For SAML: Use SAML Chrome Panel or SAML-tracer
    • Confirm groups claim contains expected values
  2. Check Role Assignment:
    • After login, verify user role in Organization Settings → Members
    • Admin users see full settings access and can manage members
    • Operators have standard access to make and manage calls
    • Viewers have read-only access to view calls and analytics
  3. Test Different Scenarios:
    • User with single group membership
    • User with multiple groups (highest privilege wins)
    • User with no groups (defaults to operator)
    • Group name changes in IdP

​
Troubleshooting Group Inheritance

Solution:
  • Verify groups claim is configured in IdP
  • Check user is member of groups
  • Ensure groups are assigned to application (Okta)
  • Confirm groups scope is requested (OIDC)
Solution:
  • Check exact group names in token
  • Verify group name matches mapping pattern
  • Look for typos or case sensitivity issues
  • Confirm no conflicting group memberships
Solution:
  • User must log out and log in again
  • Clear browser cookies/cache
  • Verify group membership changed in IdP
  • Check IdP audit logs for group changes

​
Important Notes

  • Users signing in via SSO still need to verify their phone number during first-time setup
  • SSO users are automatically added to your organization
  • Each email domain can only be configured for one organization
  • Existing users are automatically converted to SSO on first SSO login

​
Frequently Asked Questions

Choose OIDC if:
  • You’re using modern IdPs (Okta, Auth0, Azure AD)
  • You want simpler configuration
  • You need refresh tokens
  • You’re building mobile apps
  • Starting fresh with SSO
  • Want better mobile app support
Choose SAML if:
  • Required by your IdP (Google Workspace)
  • Mandated by security policy
  • You need encrypted assertions
  • Integrating with legacy systems
  • Your organization already uses SAML for other applications
  • You require specific SAML features like encrypted assertions
Yes! You can configure multiple providers for:
  • Different domains
  • Different protocols (OIDC and SAML)
  • Different identity providers
Each domain can only be assigned to one provider.
Existing users are automatically linked when they first sign in with SSO. Their data, settings, and permissions remain intact.
Yes! We recommend:
  1. Create a test provider with a subdomain
  2. Test with a small group first
  3. Roll out to entire organization
  1. Create new provider with same domain
  2. Test with select users
  3. Delete old provider
  4. Users will seamlessly use new protocol
Contact hello@bland.ai to transfer or reset domain ownership.
SCIM support is on our roadmap. Currently, users are provisioned on first login (Just-in-Time provisioning).
Yes, toggle “Skip phone verification” when creating the provider. This is useful for organizations with strong IdP authentication.
For SAML:
  1. Get new certificate from IdP
  2. Update in Bland before old expires
  3. Test with Test button
  4. No downtime if done before expiration
Minimal data is shared:
  • Email address (required)
  • Name (optional but recommended)
  • Groups/roles (optional, for role mapping)
No passwords are ever shared or stored.

​
Getting Support

When contacting support, provide:
  1. Organization ID and Provider ID
  2. Error message and screenshots
  3. Time of error (with timezone)
  4. IdP type (OIDC/SAML) and vendor
  5. Browser console errors (F12 → Console)
  6. For SAML: Sanitized SAML response (remove sensitive data)

​
Contact Information

  • Email: hello@bland.ai
  • Documentation: This guide
  • Status Page: status.bland.ai

​
IdP Vendor Support

​
Appendix: Error Code Reference

Error CodeMeaningSolution
INVALID_ISSUERIssuer URL format invalidCheck URL format, remove trailing slash
DOMAIN_CONFLICTDomain already usedContact support to transfer domain
SSO_PROVIDER_NOT_FOUNDProvider doesn’t existVerify provider ID is correct
SIGNATURE_VALIDATION_FAILEDSAML signature invalidUpdate certificate from IdP
INVALID_CLIENT_CREDENTIALSOIDC auth failedCheck client ID/secret
ACCOUNT_LINKING_FAILEDCannot link SSO accountContact support with details
METADATA_FETCH_FAILEDCannot retrieve metadataCheck metadata URL accessibility
USER_NOT_AUTHORIZEDUser not assigned in IdPAdd user to application in IdP
⌘I