Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.requesty.ai/llms.txt

Use this file to discover all available pages before exploring further.

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.
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.
    Claim nameValueRequired
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddressuser.mailRequired
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givennameuser.givennameOptional
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surnameuser.surnameOptional
  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.

​
Group sync (optional)

You can have your IdP send a groups claim and we will route each user into a matching Requesty group, so their approved models, access lists, and budgets are inherited automatically. To enable it:
  1. In your IdP, add a groups claim or attribute to the Requesty application.
  2. Tell us the IdP group names you want mapped, and which Requesty group each should land in.
If you do not send a groups claim, new SSO users land in your organization’s default group.

​
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).
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 May 13, 2026