Skip to main content
Requesty supports enterprise SSO so your team can sign in to app.requesty.ai with the same credentials they already use. Users you provision in your IdP get access automatically, and users you remove lose access on their next session. With identity provider sync enabled, users you deprovision in your IdP are removed from your Requesty organization and their API keys are revoked automatically.
Configure SSO in the Requesty Console.
SSO is included on enterprise plans. Email [email protected] (or talk to your account team) and we will turn it on for your organization. Most customers are live the same day.

​
Supported identity providers

Microsoft Entra ID

Formerly Azure AD. SAML 2.0, with enterprise applications, attribute mappings, and Conditional Access.

Okta

SAML 2.0 via an Okta Workforce application.

Any OIDC or SAML provider

Google Workspace, JumpCloud, OneLogin, Ping Identity, Auth0, Keycloak, ADFS, or any other IdP that supports SAML 2.0 or OIDC.

​
How it works

  • Domain based routing. Once we have linked one or more email domains (for example acme.com) to your IdP, anyone signing in with an @acme.com address is automatically redirected to your IdP.
  • Just in time provisioning. The first time a user signs in via SSO, they join your Requesty organization automatically. No manual invite needed.
  • Existing accounts are linked. If someone in your domain already had a Requesty account before SSO, their account is linked to the SSO connection on first sign-in. No data is lost.
  • No passwords to manage. Users do not set a Requesty password. Access is controlled entirely by your IdP, so disabling the IdP account revokes Requesty dashboard access on the next session.
  • Existing groups and policies still apply. SSO users land in your organization’s default group and inherit its approved models, access lists, and budgets. You can move them between groups at any time.

​
How setup works

Setup is a short back and forth between your IdP admin and the Requesty team. You do not need to deploy anything.
1

Tell us your IdP and email domain

Email [email protected] with:
  • Your identity provider (Entra ID, Okta, or which OIDC / SAML product).
  • The email domain(s) you want to route through SSO (for example acme.com, acme.co.uk).
  • The Requesty organization you want the connection attached to.
We create the connection on our side and reply with the values your IdP needs:
  • SAML: an Identifier (Entity ID) and a Reply URL (Assertion Consumer Service URL).
  • OIDC: an Authorized redirect URI.
2

Configure the application in your IdP

Use the values we sent to register Requesty in your IdP. Pick the tab for your provider below.
  1. Create a new enterprise application in Microsoft
    1. Navigate to the Microsoft Azure portal and sign in.
    2. Under Azure Services, find and select Enterprise applications. You may have to go to All services and scroll down to Identity to find it.
    3. Select New application > Create your own application.
    4. In the modal, give the app a name (for example Requesty SSO), select Integrate any other application you don’t find in the gallery (Non-gallery), then select Create.
  2. Assign users or groups
    1. In the Getting Started section, select Assign users and groups > Add user/group.
    2. Select the None Selected link, pick the users or groups who should have access, then select Select and Assign.
  3. Set Basic SAML Configuration
    1. In the navigation sidebar, open Manage > Single sign-on.
    2. In Select a single sign-on method, select SAML.
    3. In Basic SAML Configuration, select Edit and paste the values we sent:
      • Identifier (Entity ID): the Entity ID from Requesty.
      • Reply URL (Assertion Consumer Service URL): the ACS URL from Requesty.
    4. Select Save and close the panel.
  4. Verify Attributes & Claims Your SAML responses must include these attributes. They are the Entra defaults, so you usually do not need to change anything. Many SAML errors come from incorrect attribute mappings, so it is worth double checking.
  5. Share the App Federation Metadata URL with Requesty
    1. On the Set up Single Sign-On with SAML page, find the SAML Certificates section.
    2. Copy the App Federation Metadata Url and send it to us.
    Once we paste it on our side, the connection is ready to test.
3

We finish the connection and run a test sign-in

Once you send back the metadata URL (SAML) or the discovery endpoint plus client credentials (OIDC), we plug them into the connection, run a test sign-in with one of your users, and enable the connection for the domains you listed.At that point, anyone with a matching email domain is redirected to your IdP at sign-in and sign-up.
Want to test SSO before rolling it out org wide? Send us a test email domain or a single test user. We can enable SSO for just that subset first, then expand once you are happy. We also recommend coordinating the cutover at an off peak time, so that anyone affected can re-test if there is a misconfiguration.
By default, SSO matches the exact email domain you give us. A connection on acme.com does not match [email protected]. If you need subdomain matching, tell us when you email and we will enable it on the connection.

​
Identity provider sync

Identity provider sync keeps Requesty in step with your identity provider through directory sync (SCIM provisioning). It covers two things: syncing group membership from your IdP into Requesty groups, and automatically deprovisioning users you remove in your IdP. It is separate from SSO sign-in but requires an SSO connection, since the IdP directory is linked to your organization through that connection. Any identity provider connected through SSO can drive the sync.
Identity provider sync is off by default. Email [email protected] to turn it on, either in the same email as your SSO setup or later. We send you the provisioning details to configure in your identity provider.

​
Group sync

When a user belongs to a group in your IdP, Requesty makes them a member of the Requesty group with the same name:
  • If no group with that name exists, Requesty creates it with no budget set. Group names are unique within an organization.
  • If a group with that exact name already exists, the user is added to it.
  • The user gets the regular member role in synced groups.
  • Groups apply once the user is a member of your Requesty organization. If the IdP update arrives before the user joins, the sync completes when they join.
  • Users land in your organization’s default group when no IdP groups apply.
Synced groups behave like any other group: admins can set budgets, access lists, approved models, and guardrails on them in Admin Panel → Groups.
Group sync is additive only. Removing a user from an IdP group does not remove them from the Requesty group, and deleting a group in the IdP does not delete it in Requesty. Remove memberships or groups in Admin Panel → Groups if needed.

​
Deprovisioning

When a user is deprovisioned in your IdP, Requesty automatically:
  • deletes all API keys the user owned in the organization, which immediately revokes API access through those keys;
  • removes the user from all of the organization’s groups;
  • removes the user from the organization;
  • deletes the user’s Requesty account.
This only happens for organizations with identity provider sync enabled.
Deprovisioning deletes the user’s personal API keys. Production workloads should authenticate with service accounts, which are not tied to a user.

​
Audit trail

Groups created and memberships added by the sync appear in Admin Panel → Audit Logs with the actor “Identity provider”.

​
What SSO does and does not change

No. SSO controls who can sign in to the Requesty dashboard. API requests to router.requesty.ai still authenticate with your API keys and service accounts. That is intentional, so your production agents keep working even if a user leaves the company.To rotate access for a departing employee:
  • Disable them in your IdP. They lose dashboard access on the next session.
  • Revoke or transfer any API keys they personally owned (the Admin Panel shows API keys per user). With identity provider sync enabled, deprovisioning the user in your IdP deletes their API keys automatically.
Yes. Once a connection is enabled for your domain, all users with a matching email address are redirected to your IdP at sign-in and sign-up. Email or social sign-in is no longer an option for those users, so people cannot bypass your IdP.
Their account is reused. The next time they sign in, they are redirected to your IdP, and once they authenticate the existing account is linked to the SSO connection. Email verification on the IdP side counts as verification on our side, so password prompts are skipped. No data is lost.
Yes. SSO is independent of EU routing. You can sign in via your IdP and still send API traffic through router.eu.requesty.ai to keep request processing in the EU.
The users created via SSO are not deleted, so your app keeps working. They will need to sign in with another method (email code, social) the next time they come back.
Yes. Self hosted Requesty supports SSO via Microsoft Entra ID (MSAL) or any OIDC provider (Google, Okta, GitHub, GitLab, generic OIDC) through the bundled SSO handler. Contact us for the self hosted setup guide.

​
Need help?

Talk to us

Email [email protected] with your IdP and email domain(s), or ping your account team. We will guide you end to end and most customers are live the same day.
Last modified on October 5, 2026