When you are uncertain of a customer's idpId value, you can use IdP Discovery to specify the email domains associated with the customer (see Edit an invited customer connection). Alternatively, you can find the idpId in one of these ways:

Applications having multiple login URLs
Some cloud applications use a different login URL for each customer organization. If your application works this way, use URL-based IdP discovery, looking at the URL itself to find the idpid.

For example, if the customer is "Acme" and your application domain is "example.com", the login URL is similar to this:

   https://acme.example.com/login

In this case, use "acme" as the idpid value.

Applications having a single login URL
Some cloud applications use a single login URL for all of their users, and associate the users with an organization after they are logged in.

If your application needs to work this way, you can specify the corporate identifier as the idpid parameter value in the request. For example:

https://sso.connect.pingidentity.com/sso/idp/SSO.saml2?idpid=customer001.com

You can also use cookie-based IdP discovery (see below) in conjunction with this method.

Cookie-based IdP discovery
You can also store the user information in a cookie. However, you can only use this method when the user has signed on (SSO) previously using the same browser. Because this cannot be the only method used to find the IdP, you will need to use it with another discovery mechanism.

To use this method, when a user signs on (SSO), your application does a token exchange with PingOne to identify the user and create a session. When creating the user session, you will also have access to the idpid value, since it is one of the attributes supplied during the token exchange. You can then store this idpid value in a persistent cookie (named "idpid", for example). For subsequent user sign-ons, you then read the value from the request.