SAML Metadata - Incorrect Assertion Consumer Service URL?

I apologize if this is a basic question, but we’re facing an issue with our SAML configuration. The security team flagged an incorrect Assertion Consumer Service (ACS) URL in the metadata document. It’s… confusing, because the ACS URL in the metadata doesn’t match what’s configured in Genesys Cloud.

We’re using the Genesys Cloud REST API to manage the SAML integration. The configuration appears correct in the API response when we GET the SAML settings. The ACS URL in the response is https://login.genesyscloud.com/connect/saml. However, the metadata document downloaded from the same endpoint shows https://genesyscloud.com/connect/saml.

The metadata is used by our IdP - we’re using Okta - so this mismatch is causing authentication failures. We’ve tried refreshing the metadata, but it doesn’t resolve the issue. It’s impacting our SOC2 audit because it’s a deviation from documented secure configuration.

The SDK version we’re using is 6.1.0. We’ve checked the documentation regarding metadata updates and URL formats, but it doesn’t appear to address this specific discrepancy. Is the genesyscloud.com domain valid for the ACS URL in the metadata, or is there something wrong with our configuration? Also, should the metadata URL be the same as the login URL? This is causing some uncertainty.

We are on genesyscloud.configcloud.jp - region is APAC.

That’s right, and it’s almost always a caching issue. We’ve got around 1800 agents and ran into this a couple times. The metadata endpoint doesn’t always refresh immediately after an update via the API.

Good. You’re on the right track. Try forcing a metadata refresh. You can do that by sending a PUT request to /api/v2/identityproviders/generic with the updated configuration. This triggers a re-generation of the SAML settings. Give it a couple minutes, then re-download the metadata.

Side note - if you’re automating this, add a retry loop with exponential backoff. The endpoint can take a surprising amount of time to respond.

Are you pulling the metadata directly from the GET /api/v2/identityproviders/generic endpoint, or generating it some other way; because the API’s insistence on returning XML is…a choice? Anyway, you can force a refresh by calling PUT /api/v2/identityproviders/generic-it won’t tell you it did anything, naturally; it just…does. It’s a bit of a hidden thing; but it works.

I tried the POST request to force a refresh, but the ACS URL is still wrong in the XML. It is not updating to the new value.