Single Sign-On (SSO)

Single sign-on in Hi.Events lets your team sign in to your account through your company’s identity provider, such as Okta, Microsoft Entra ID or Google Workspace, instead of a separate Hi.Events password. When someone leaves your company and you turn off their account in your identity provider, they can no longer sign in here either.

Hi.Events connects to identity providers using OpenID Connect (OIDC). SAML isn’t supported.

How to Get There

1. Click your profile icon and choose Account Settings
2. On the General page, find the Single sign-on section

Only admins see this section, and only once single sign-on is switched on for your account. Click Set up SSO to start. Once a connection exists, the section shows its status:

Click Manage single sign-on to change anything. Setup and changes happen in a panel with six steps.

1. Choose Your Identity Provider

Pick the provider your company uses:

• Okta
• Microsoft Entra ID (formerly Azure Active Directory)
• Google Workspace
• Other OIDC provider: Keycloak, Authentik, Zitadel, OneLogin and others

2. Connect Your App

Hi.Events shows step-by-step instructions for your provider. In short, you create an app in your identity provider, give it the Redirect URI shown in Hi.Events (copy it exactly), and paste the app’s details back in:

For Microsoft Entra ID, also add the optional claims email and xms_edov to the ID token, as the instructions describe. Without them, Hi.Events can’t tell that an email address is verified.

Click Save Okta connection (the button names your provider) to store it. When you’re editing an existing connection, the button is Save changes. The client secret is kept hidden afterwards. To change it, click Edit details and enter a new one, or leave it blank to keep the current secret.

3. Test Sign-In

Click Test sign-in and sign in with your identity provider in the window that opens (on a phone, it opens in the same tab). This checks the connection without signing you in to Hi.Events. The result shows what your provider shared: your name, your email and whether it’s marked as verified, whether its domain is verified yet, and any groups.

People can only join, or be matched to an existing Hi.Events login, when your provider marks their email as verified. If the test shows Not marked as verified, fix that in your identity provider before going further.

4. Verify Your Email Domains

Single sign-on only applies to people whose email is on a domain you’ve verified, such as yourcompany.com.

1. Type the domain and click Add domain
2. Add the TXT record Hi.Events shows (Name and Value) at your DNS provider
3. Click Verify

Subdomains need their own record. A domain can only be verified on one Hi.Events account. Personal email domains such as gmail.com can’t be used, and you can add up to 20 domains.

Hi.Events checks the record again every day, so leave it in place. If the check fails, the domain shows Failing since and how long ago it started failing, and single sign-on keeps working for it in the meantime. After 7 days of failing it becomes Suspended, and single sign-on stops applying to that domain. Restore the record and click Verify, or wait for the next daily check to find it.

5. Sign-In Settings

6. Choose Who Must Use It

Turn on Require single sign-on when you want everyone with an email on a verified domain to sign in through your provider. This needs sign-in turned on, at least one verified domain, and two-factor authentication turned on for the account owner.

Before anything changes, Hi.Events shows a preview: how many members will need to use single sign-on, how many outside your verified domains keep their current sign-in, and a list of affected members. Switch on Exempt for anyone who should keep signing in with a password, then click Require single sign-on.

When it’s on:

• Affected members are signed out everywhere and must sign in again through your provider. If you’re one of them, you’re signed out too
• Their API keys for this account are revoked, so anything using those keys needs a new one
• Nobody can sign up for Hi.Events with an email on a verified domain. They’re sent to single sign-on instead
• Members who own another Hi.Events account are marked in the preview as keeping their password, and keep signing in with it
• You can change each member later: click Exempt to let them use a password, or Require SSO to bring them back

The member list on the Team page shows a badge for how each person signs in: SSO, Exempt or Password.

To turn it off, switch off Require single sign-on and click Stop requiring. Members can sign in with their password again, or reset it if they never had one.

The Account Owner’s Backup Sign-In

The account owner is never required to use single sign-on. They keep their password, and two-factor authentication protects it: it’s always asked for, and it can’t be turned off while single sign-on is required. This means you can still get into your account if your identity provider is down.

Every admin is emailed whenever the owner signs in this way, so a backup sign-in never goes unnoticed.

The owner always signs in this way: Sign in with SSO won’t sign them in. The same goes for anyone on your team who owns another Hi.Events account.

How Your Team Signs In

1. On the Hi.Events sign-in page, click Sign in with SSO
2. Enter their Work email and click Continue
3. Sign in on your identity provider’s page

If you’ve invited someone whose email is on a verified domain, signing in through single sign-on with that email accepts their invitation.

Changes and Notifications

• The account owner is emailed when someone else connects, changes or deletes the provider, turns sign-in on, or starts or stops requiring single sign-on
• Turning sign-in off signs out everyone who has ever signed in through it, from every device, and deletes their API keys for this account
• Changing the issuer, tenant, Workspace domain or client ID does the same and turns sign-in off. Run a new test sign-in, then turn it back on. You have to stop requiring single sign-on before you can change these details
• To switch to a different provider, stop requiring single sign-on, delete the connection and set up a new one
• To remove the connection, stop requiring single sign-on, then click Delete connection. This also signs those people out and deletes their API keys for this account. Members who only signed in through it will need to reset their password
• A verified domain can’t be removed while single sign-on is required

Tips

• Before requiring single sign-on, the account owner has to turn on two-factor authentication. Make sure they’ve saved their recovery codes too. That’s your way back in if your identity provider has an outage
• Tell your team before you require it. Everyone affected is signed out straight away, and any API keys they use stop working
• Use Viewer as the Role for new people if you add people automatically, then raise roles by hand on the Team page
• Leave the DNS TXT record in place after verifying. Removing it suspends the domain after 7 days
• If you get stuck, email [email protected] with your provider’s name and what the test sign-in showed

Last updated 20 October 2026