Postman alternative with SAML SSO and SCIM

Postman alternative with SAML SSO and SCIM: what your identity controls require

An identity or security team that must bring API client sign-in, user lifecycle and audit evidence under its own controls should know that self-hosted Hoppscotch Enterprise Edition and Bruno's paid editions can meet SAML SSO and SCIM on your own servers, while the Hoppscotch Community Edition and offline-only Bruno do not provide these controls. Postman places SAML SSO in its Team add-on and advanced security administration in its Enterprise plan, so the cost of identity integration on the Postman side is tied to those tiers. Start by writing down which of these controls your policy requires: federated sign-in through your identity provider, automatic deprovisioning when someone leaves, group-based access, and an audit trail of who changed shared collections.

Hoppscotch Enterprise Edition adds SCIM user and group provisioning, activity and audit logs and user groups on top of SAML-based SSO and OpenID Connect. It requires a license key, so confirm with the vendor how that key is issued and renewed, and whether SCIM and audit logs are covered on the server you plan to run. Bruno's paid editions manage license keys in a license portal that also covers SAML single sign-on and SCIM provisioning. Ask Bruno which SAML and SCIM settings the portal exposes, and whether they apply to the Git-based collection workflow or only to the app itself, since collections remain plain files in a folder that anyone with repository access can read.

Your identity provider or a self-hosted broker such as Keycloak, which supports SAML 2.0 and OpenID Connect, can sit in front of either tool, but that adds an identity server to operate. Decide who owns sign-in, token lifetimes and SCIM endpoints before you compare prices, because the operating cost of the identity layer often outweighs the license fee. Confirm the exact provisioning behavior, log retention and group mapping with each vendor in writing, and test deprovisioning with a disposable user before rollout.

Which identity requirements an API client must meet

An API client that holds production tokens and internal endpoints sits inside your identity perimeter, so it needs the same controls as any other business system. The four requirements below connect sign-in, lifecycle, audit and data location, and each one is checked against the editions and sign-in methods that the vendors document.

Federated SAML or OIDC sign-in

Federated sign-in means users authenticate with your identity provider instead of a separate password held by the client. Hoppscotch Enterprise Edition supports SAML-based SSO and OpenID Connect, while the Community Edition signs users in through Email, GitHub, Google and Microsoft OAuth providers that the administrator configures. Check whether your identity provider is a SAML or OIDC source, and confirm that a personal social login is not your only path in.

SCIM user and group provisioning

SCIM lets your identity provider create, update and remove client accounts automatically, so access ends when an employee leaves. Hoppscotch Enterprise Edition adds SCIM user and group provisioning and user groups, which Community Edition does not provide. Ask the vendor how deprovisioning behaves for workspaces that a removed user owned, and test that a disabled account loses access to shared collections.

Audit and activity logs

Audit logs record who changed a collection, read an environment or altered a shared workspace, which investigators need after an incident. Hoppscotch Enterprise Edition includes activity and audit logs, and Bruno's paid editions run through a license portal that covers SSO and SCIM. Confirm the retention period, log export format and whether logs reach your SIEM before you rely on them for evidence.

License control and vendor-managed access

Paid editions need a license key, and access to features such as SSO depends on that key staying valid. Hoppscotch Enterprise Edition requires a license key, and Bruno's paid editions manage keys in a license portal that also covers SAML single sign-on and SCIM provisioning. Ask who holds the administrator role in the portal, how keys rotate, and what happens to sign-in if a renewal lapses.

Data kept on infrastructure you control

Identity controls do not help if collections, environments and embedded credentials sit in a vendor cloud outside your review. Self-hosted Hoppscotch keeps team workspaces in your PostgreSQL database, and offline Bruno stores collections as files in a folder you choose. Map where each data type lands, including logs, backups and SMTP email, and confirm that no feature silently syncs to a hosted service.

How Hoppscotch Enterprise, Bruno paid editions and Keycloak compare on SSO and SCIM

Hoppscotch Enterprise Edition is the self-hosted option that covers the identity features most often asked for in regulated teams. It is licensed separately from the MIT-licensed Community Edition and requires a license key to run. Its documentation lists SAML-based single sign-on, OpenID Connect, SCIM user and group provisioning, activity and audit logs and user groups. Your team still operates the instance, so your platform staff own upgrades and backups.

Sign-in protocols: SAML-based SSO and OpenID Connect are both listed, so most enterprise identity providers can be connected.
User provisioning: SCIM provisioning for users and groups lets your identity provider create and deactivate accounts without manual steps.
Audit trail: Activity and audit logs are included, which supports access reviews and incident investigation.
Licensing: A license key is required. Hoppscotch's pricing page lists Enterprise at $11 per user per month, billed annually, for its cloud service, so confirm with Hoppscotch how a self-hosted Enterprise license is priced.
Operations: Enterprise includes priority support and guaranteed quarterly updates, but you still install and run the containers.

Confirm with Hoppscotch which SAML and SCIM features apply to your identity provider, how the license key is issued and renewed, and whether the audit log format meets your retention rules.

How to deploy self-hosted Hoppscotch Enterprise with SAML and SCIM

This sequence takes a team from an identity provider decision to a self-hosted Hoppscotch Enterprise instance that signs users in through SAML or OIDC, provisions users and groups through SCIM, and writes audit logs you can review.

Confirm scope and the identity provider
The platform owner and the identity team agree in writing which users, workspaces and groups are in scope, and which identity provider will act as the source of truth. Confirm that the provider supports SAML 2.0 or OpenID Connect and SCIM provisioning, and check the SAML or OIDC metadata and redirect values the provider will need. Ask the Hoppscotch sales or support team to confirm which Enterprise features are covered by your license before you start, because the Enterprise Edition requires a license key. The step is done when you hold a signed scope note, a named identity provider owner and a list of the claims you expect to receive.
Provision the Docker or Helm deployment
The infrastructure team deploys the Hoppscotch Community Edition base using the Docker containers or the Helm chart for Kubernetes, following the install and build and deploy and upgrade guides for the version you intend to run. Set the PostgreSQL connection string through DATABASE_URL and confirm the database is reachable from the application containers and backed up according to your own policy. Check the prerequisites page for the CPU and memory needed for the build and hosting steps. The step is done when the frontend, backend and admin services start and the database connection is confirmed in the logs.
Configure SMTP and the first administrator
Set the SMTP settings the instance needs for email, since Community Edition relies on email for sign-in and notifications. Send a test message from the mail relay to confirm delivery from the instance hostname. Create the first administrator account through the documented bootstrap process and record the account in your privileged access register. Keep the administrator credentials out of Git and out of shared collections. The step is done when a test email arrives and the administrator can sign in to the admin interface.
Install the Enterprise license key
The platform owner adds the Enterprise Edition license key to the deployment configuration, following the Enterprise Edition documentation, and restarts the services so the enterprise features load. Store the key in your secrets manager rather than in a repository or a compose file that is committed to Git. Record the key holder and the renewal contact. The step is done when the admin interface shows the Enterprise features as active and the license state is recorded in your change log.
Connect SAML or OIDC single sign-on
The identity team registers the Hoppscotch instance as a relying party in the identity provider using the SAML or OpenID Connect values from the Enterprise configuration, and the platform owner enters the provider metadata or client details into the instance. Map the email and name attributes, and test sign-in with a pilot account that is not an administrator. Confirm that sign-out and session timeouts behave as your identity policy requires. The step is done when a pilot user signs in through the identity provider and lands in the correct workspace.
Enable SCIM user and group provisioning
The identity team creates the SCIM connector in the identity provider, pointing it at the Hoppscotch SCIM endpoint and using the token the instance issues. Start with a small test group, then expand the assignment once create, update and deactivate events behave as expected. Confirm that a removed user loses access in the instance, because deprovisioning is the main control SCIM adds. The step is done when a test user is created, updated and deactivated from the identity provider and the change appears in the instance.
Set user groups and workspace access
The platform owner maps identity provider groups to Hoppscotch user groups and assigns workspace permissions to each group, keeping the least-privilege model your access review requires. Document which group owns each shared collection and who can approve changes to it. Review the groups with the identity owner before production use. The step is done when each workspace has a named owner group and a test user in each group sees only the workspaces assigned to that group.
Test audit log output and document the result
Perform a few controlled actions in a test workspace, such as creating a collection, changing an environment and removing a user, then confirm that the activity and audit logs record each event with the correct user and timestamp. Export or forward the logs to the destination your security team uses, and confirm that the retention period meets your policy. Ask the vendor to confirm the retention and export options for your edition. Record the test cases and results in your control evidence. The step is done when the logs match the test actions and the evidence pack is filed for review by your internal or external assessors.

What stays in your control when collections never leave your servers

Keeping collections on your own infrastructure only protects embedded credentials if you know where each one is stored. With self-hosted Hoppscotch Community Edition, workspaces, collections and environments sit in the PostgreSQL database named in DATABASE_URL, so the database host, its backups, its encryption settings and its network access rules become your controls to define. With Bruno, collections are plain files in a folder on the user's filesystem and in the Git repository the team commits them to. Your controls there are the repository's access model, branch protection, and a rule that secrets live in environment files or an external secrets manager rather than in committed request files. Confirm with each vendor how environment secrets are stored and whether they are encrypted at rest before you migrate a production collection.

Sign-in is the other half of the control picture, and it is only as strong as the identity provider behind it. Enterprise Edition of Hoppscotch adds SAML-based SSO, OpenID Connect and SCIM provisioning, so deprovisioning a leaver in your IdP should remove their access to team workspaces. Test that path with a disposable account rather than assuming it works. For Bruno, SAML single sign-on and SCIM are managed through its paid license portal, so confirm the entitlement before you plan around it. Users who previously signed in to Postman cloud accounts will lose synchronized collections when they move, so export their work first, reissue their access through the new sign-in method, and agree with them who owns each shared collection after the switch.

Evidence to collect for SSO, SCIM and audit reviews

A Hoppscotch Enterprise Edition or Bruno paid deployment is only as reviewable as the records behind it. The cards below list the artifacts an internal reviewer or external auditor is likely to ask for, and what each one should show. DeployOpen prepares these artifacts, but independent auditors issue any assessment or attestation.

SAML and OIDC configuration exports

Capture the identity provider settings used for sign-in: entity IDs, redirect and callback URLs, signing certificate expiry dates, and the attribute mappings for email and group claims. Store the exports under version control with change approvals, so a reviewer can see who changed a trust relationship and when. Confirm with Hoppscotch and Bruno which settings their Enterprise and license-portal SSO flows expose for export, since the exact export format is not something to assume.

SCIM provisioning logs

Keep the record of user and group creation, update and deactivation events pushed from your identity provider. These logs show whether leavers lost access in a timely way, and they are the first evidence an auditor will request for access removal. Ask your identity provider and Hoppscotch Enterprise Edition for log retention periods in writing, and export them to storage you control before any vendor-side window closes.

User group mappings

Document which identity provider groups map to which Hoppscotch workspace roles or Bruno license seats, and who approved each mapping. Reviewers test least privilege by comparing these mappings against the actual memberships. A mapping that grants a broad group write access to shared collections is a finding even when the sign-in itself is correct.

Audit log samples

Hoppscotch Enterprise Edition includes activity and audit logs. Pull dated samples covering logins, role changes, workspace sharing and deleted collections, and check that each entry names an actor and a target. Confirm the log fields and retention with the vendor, and forward logs to your central SIEM where you can keep them for the period your policy requires.

License record and entitlement history

Keep a dated record of every license key or license portal entry, the number of seats purchased, the editions covered, and the owner of the account. Hoppscotch Enterprise Edition requires a license key, and Bruno's paid editions use license keys managed in a license portal. Reconcile seat counts against active identities each quarter so that the record matches what users actually hold.

Upgrade history and change records

Maintain a log of every deployed version of the self-hosted instance, the date it went live, the test evidence collected before the change, and the rollback plan. Hoppscotch Community Edition is updated by the user, and Hoppscotch Enterprise Edition carries guaranteed quarterly updates. Reviewers look for approved change tickets, not just a current version number, so tie each upgrade to a ticket and a test run.

Questions buyers ask before choosing a self-hosted SSO and SCIM setup

How does Hoppscotch Enterprise cost compare with Postman Team seats?

Hoppscotch's pricing page lists Enterprise at $11 per user per month and Business at $6 per user per month, both billed annually, which is the only list price set you can compare directly. Postman's Team plan price is not in the supplied facts, so check Postman's current About plans page for the seat price and whether SSO sits in a Team add-on. Hoppscotch Community Edition is free to run, but you still pay for the server, PostgreSQL, SMTP, and staff time to upgrade it. Ask any vendor for a per-seat quote with the annual or monthly term and the add-on fees itemized.

What drives the effort of a self-hosted SSO and SCIM setup?

The main drivers are the number of identity sources, how many groups need mapping to Hoppscotch roles, and whether provisioning must run automatically from your directory. Hoppscotch Enterprise adds SAML-based SSO, OpenID Connect, SCIM user and group provisioning, and audit logs, and each one needs its own configuration and testing. The Community Edition needs Docker containers, a PostgreSQL database set through DATABASE_URL, and SMTP for email sign-in, which adds infrastructure work before identity work starts. Effort falls when your IdP already supports SAML and SCIM and your group structure is clean.

Can our team deploy Hoppscotch with SSO without outside help?

Yes, a team with container, database and identity experience can deploy the Community Edition from the documentation, but SAML, OIDC and SCIM with audit logs require a license key and careful testing. Hoppscotch's documentation describes Community Edition as installed, administered and updated by the user, with community forum support. Enterprise adds priority support and guaranteed quarterly updates. Decide early which parts your staff will own, such as upgrades, backups and access reviews, and which parts you want to hand to a fixed-scope engagement.

How long does a self-hosted SSO and SCIM project usually take?

The timeline depends mostly on identity setup, not on the Hoppscotch install itself. A tenant with a single IdP, standard SAML attributes and a few groups moves much faster than one with multiple directories, custom claims or manual user lifecycle steps. Each SCIM mapping needs testing with real joiner, mover and leaver cases. DeployOpen plans these engagements as fixed-scope projects, so scope, deliverables and timelines are agreed in writing before work starts, and the discovery step shows your real identity complexity.

What do we need from our IdP and security teams?

Your identity team must provide SAML metadata or OIDC client settings, an agreed attribute mapping, group claims, and a service account with rights to run SCIM provisioning. Your security team should approve the callback URLs, certificate handling, retention rules for the audit logs, and how administrator access is reviewed. Confirm with your IdP vendor which SCIM features it supports before you commit, since provisioning behavior varies by product. Plan change windows for certificate rotation so sign-in does not break unexpectedly.

Can Keycloak replace a commercial identity provider for this setup?

Keycloak can act as the identity provider in front of Hoppscotch because it supports OpenID Connect and SAML 2.0 and provides single sign-on, user federation and an admin console. It is licensed under Apache 2.0 and is a CNCF incubating project. Whether it replaces your commercial IdP depends on your directory, MFA, lifecycle tooling and support needs, and SCIM provisioning must be verified against your Hoppscotch edition. Keycloak runs on supported databases such as PostgreSQL, and its operator needs a synchronously replicated database for high availability. Confirm these items in a proof of concept before you decide.

What operational work continues after the SSO setup goes live?

Recurring work includes Hoppscotch upgrades, which the Community Edition expects you to apply yourself on a quarterly release cadence, plus certificate renewals, SMTP monitoring and PostgreSQL backups. If you use Keycloak, plan for its four minor releases a year and check breaking changes, which are opt-in in minor releases. Operator updates should use manual approval mode, as the Keycloak Operator documentation recommends. Ask any provider which of these tasks sit inside a retainer and which remain with your team.

Migrating Postman collections once SSO is in place

Move the people before the collections. Shared collections should only land in a new home once every user who needs them can sign in through the identity provider and has a role in the target workspace. For a self-hosted Hoppscotch Enterprise Edition, that means SAML or OpenID Connect sign-in works, SCIM has provisioned the user groups, and a pilot team has confirmed access to a test workspace. Confirm with your identity team which attributes SCIM will send and whether group membership maps cleanly to the workspace roles you plan to use. Collections imported before this check tend to end up owned by a single administrator, which makes later permission changes harder.

Choose the import path by what you are moving. Hoppscotch's importer accepts Postman collections and environments, with a 50 MB limit on self-hosted editions, so check the size of your Collection v2 or v2.1 exports first and split very large ones. Bruno imports the same JSON formats, and its Migrating from Postman guide describes bulk import of a full data dump as part of Bruno Ultimate Edition, so confirm whether that edition is in your budget before you plan a bulk move. Bruno writes collections as files in a folder, which means the result belongs in Git under your normal review controls, but it does not provide SSO on its own. The SSO and SCIM items on your list apply to the Hoppscotch path and to Bruno's paid license portal, not to the local files.

Plan for script translation gaps before cutover. Bruno translates common Postman script APIs such as pm.test, pm.environment and pm.response, but flags packages such as postman-collection and newman as unsupported. Hoppscotch scripts also need review, since they do not run unchanged. Run a sample of the highest-use requests against the target and compare results with the Postman originals. Keep the Postman account active and read-only until each team has signed off, and confirm the retirement date for any Postman features you still depend on with Postman's own documentation.

How DeployOpen deploys API client SSO under your constraints

Every engagement starts with a written scope that names the client platform, the identity provider, the user and group population, the environments and the deliverables. DeployOpen plans the work with your security, platform and identity teams before any system is touched, so the boundaries of responsibility are clear. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope rather than from a published price list.

Platform choice: Confirm whether the target is Hoppscotch Enterprise Edition, Bruno with a paid license, or a mix, based on the SSO and SCIM requirements you actually have.
Identity sources: Record which identity provider, protocol (SAML, OIDC or both) and provisioning path will be used, and who owns each one.
Data locations: Name the infrastructure, accounts or networks where collections, environments and audit logs will live.
Deliverables: List the configuration, runbooks, test results and evidence items that will be handed over.
Exclusions: State what is out of scope, such as migrating collections or building custom integrations.

Ask for the written scope to be reviewed against your access policy before signing.

Postman alternative with SAML SSO and SCIM on your own servers