CrowdStrike Connector Was Working fine until 10/22/2026

Hello @EricK.85454 (Customer)​ Thank you for posting on our Community page!

You are asking why reauthorizing the Okta Workflows CrowdStrike Falcon connector fails with "HTTP Error: {"error":{"status":500,"message":"Bad Request"}}" on 10/22/2026, when the API client and its secret have not changed, and how to isolate the cause.

Your reading of the error is correct: the 500 is the connector's wrapper, and the underlying failure is an HTTP 400 returned by the CrowdStrike Falcon OAuth2 token endpoint. The fix is to identify why Falcon rejects the client credentials request, which usually comes down to the credentials, the cloud region, or the way the connection sends them.

Root Cause: Okta Workflows exchanges the client ID and client secret for an access token by POSTing them to the Falcon /oauth2/token endpoint. Falcon returns 400 when it cannot issue a token for the request as sent. Because the client and secret are unchanged, the likely causes are a mismatch between the credentials and the Falcon cloud the token URL points to, a value that differs from what Falcon holds (such as stray whitespace from copy and paste or a secret that was rotated elsewhere), or a change in how the connection submits the credentials.

Solution: Work through the following checks in order.

1. Open the Workflows flow run history for the failed reauthorization or the flow that calls the connector, and read the full response body from Falcon. The body of the 400 usually names the problem (for example, an invalid client), and that message narrows the cause faster than the wrapper error.
2. Confirm the API client still exists and is enabled in the Falcon console under Support and resources → API clients and keys. If it is missing or its scopes no longer cover the operations you use, create a new API client with the required scopes and update the Workflows connection with its ID and secret.
3. Confirm the cloud region. Falcon API clients belong to a specific CrowdStrike cloud (for example, US-1, US-2, or EU-1), and each cloud has its own base URL and token endpoint. If the token URL in the connection points to a different cloud than the one that issued the client, Falcon rejects the request. Match the base URL in the connection to the cloud shown for your API client.
4. Re-enter the client ID and client secret in the Workflows connection. Paste the values without leading or trailing spaces, because a single extra character causes a token request to fail.
5. Reauthorize the connection and check that the connection uses the built-in Client Credentials option. Per the Okta Workflows community guidance, the built-in option sends the credentials in the request body and not as a Basic authorization header. If Falcon requires a different method for your setup, a custom request with the auth type set to None is the documented alternative, and it must follow the vendor's exact token request format.
6. Check that only one Authorization header is sent on requests to Falcon. A second connection attached to the same card can add a conflicting header and cause the API to fail.

If the Falcon response body does not identify the cause after these checks, contact Okta Support with the flow run ID, the connection name, and the full error text so the connection and the Falcon token exchange can be verified on your account.

Thank you for reaching out to our Community and have a great day!

--

Help others in the community by liking or hitting Select as Best if this response helped you.