SAML SSO breaking OAuth client credentials flow for API scripts

We recently flipped the switch to SAML SSO for all our agents and supervisors. It’s working great for the UI, but now my Python script that handles bulk user provisioning is getting rejected. The script was using a standard OAuth2 client credentials flow with a specific API key and secret.

Here’s the flow:

import requests

url = "https://api.mypurecloud.com/oauth/token"
headers = {"Content-Type": "application/x-www-form-urlencoded"}
payload = {
 "grant_type": "client_credentials",
 "client_id": "my_api_key",
 "client_secret": "my_secret"
}

response = requests.post(url, headers=headers, data=payload)
print(response.status_code)
print(response.json())

I’m getting a 401 Unauthorized response. The body says invalid_client. I checked the Admin console under Security > Integrations. The API key is still there and marked as active. I assumed SAML only affected human login via the browser.

Wait, maybe I need to do something different? I see options for “SAML” and “OAuth” in the security settings. Did enabling SAML disable the ability to generate new client credentials? Or do I need to attach the API key to a specific service account that has SSO enabled?

I tried creating a new integration key, but the UI won’t let me save it unless I select an authentication method. The dropdown only shows SAML. There’s no option for “Client Credentials” anymore.

Is there a way to bypass this? I can’t force every script to go through a SAML assertion flow. That’s a pain to implement in a cron job. I just want a static token or a simple POST to get a token.

Also, the documentation mentions something about “Service Accounts” in the context of SSO. Do I need to create a service account in the IdP (we’re using Okta) and then map it in Genesys? If so, how do I get the client_secret for that service account? It seems like a chicken and egg problem.

Any tips on keeping automated API access working when SSO is the primary login method?