HeimPulse

Setting up single sign-on

Connect your organization's own identity provider (IdP) so members sign in through it instead of a HeimPulse password. Works with any standard OIDC provider — Okta, Azure AD, Google Workspace, AWS Cognito, and others. Once enabled, signing in through your IdP becomes required for every member except the organization's owner, who always keeps their existing login method too — SSO can never lock you out of your own organization.

  1. 1. Register HeimPulse as an application in your IdP

    In your identity provider, create a new OIDC application (sometimes called a "client" or "app integration") with an authorization-code grant. Set its redirect/callback URL to:

    https://api.heimpulse.com/auth/sso/callback

    Your IdP will give you three things you'll need next: an issuer URL, a client ID, and a client secret.

  2. 2. Open your organization's settings

    From your organization's dashboard, go to Settings and find Single sign-on. Only an organization's owner can configure it.

  3. 3. Enter your IdP's details

    Fill in the issuer URL, client ID, and client secret from step 1, plus a login slug — a short identifier of your choosing (e.g. acme-corp) that becomes part of the sign-in link members use:

    https://api.heimpulse.com/auth/sso/<your-slug>/start

    The client secret is write-only — once saved, HeimPulse never displays it again, including to you. Changing any of these fields later resets the connection to unverified, so you'll test and re-enable it after any edit.

  4. 4. Test the connection

    Click Test connection and sign in through your IdP as you normally would. This confirms the issuer URL, client ID, and client secret actually work together — it doesn't sign you into HeimPulse or change anything for your members yet.

  5. 5. Enable it

    Once the test succeeds, click Enable. From this point on, every non-owner member of your organization must sign in through your IdP — a member's existing HeimPulse password (or Google sign-in, if that's how they signed up) stops working for this organization. You, as owner, are never affected by this — your own login keeps working exactly as before.

Inviting members after SSO is enabled

An invite sent while SSO is enabled links straight to your IdP's sign-in flow instead of asking the invitee to set a password — there's nothing for them to set. They just need an account in your identity provider under the same email address you invited.

Forgot password, once SSO is enabled

A member whose sign-in is managed by your organization's SSO (or by Google, for an account created that way) can't reset a HeimPulse password for it — there isn't one to reset. HeimPulse tells them to contact their organization's owner, or to use their normal sign-in method, instead of emailing a reset link that would never work.