Hey there I coudlnt get a relevant answer using the AI. An existing client connected okta sso and now my audit webhook connector no audit logs of their tenant appear in the coralogix that is connected to the webhook connector. Other tenants still appear as expected, and I see LoginSucceed Events in the descope audit log. And I did get the audit logs events from them before they setup the sso Is there any reason the sso would stop it from working?

Hi, I'm Descope's AI assistant. I've put together an initial response below based on your question. There is no documented behavior in Descope indicating that configuring SSO (including Okta) on a tenant would cause audit logs to stop streaming via the webhook connector. SSO configuration and audit log streaming are independent systems. Here are the most likely areas to investigate: 1. Check the Audit Webhook Connector's Tenant Filter The most probable cause is a tenant filtering misconfiguration on the connector itself. The Audit Webhook connector supports filtering by Tenants — it's possible the connector was reconfigured around the same time SSO was set up, or that the tenant filter was inadvertently changed. - Navigate to the Descope Console → Connectors → your Audit Webhook connector - Under Stream Audit Events, check whether Stream filtered audit events only is selected - If so, verify the Tenants filter — confirm this specific tenant's ID is included (not excluded) 2. Verify the Connector Is Still Active and Reachable - Confirm the Base URL pointing to Coralogix is still valid and returning a success response - Check that the authentication credentials (Bearer Token / API Key / Basic Auth) configured on the connector haven't expired or been rotated - Ensure Trust Any Certificate settings haven't changed if TLS is involved 3. Check Audit Logs For more detailed guidance, you can refer to the following documentation: - Audit Webhook Connector - Webhook Connectors - Tracking User Updates

Hi @Gal Rosenberg SSO itself doesn't affect audit webhook streaming, so the connection between those two is likely coincidental. But the fact that it's only this one tenant that stopped streaming (while others work fine and the events still appear in Descope's audit log) does point to a specific cause. The most likely culprit is the tenant filter on your Audit Webhook connector. Here's what to check: 1. Go to Descope Console → Connectors → your Audit Webhook connector 2. Under Stream Audit Events, check if "Stream filtered audit events only" is selected 3. If yes, verify the tenant filter — confirm this tenant's ID is explicitly included One thing worth double-checking: when the client set up Okta SSO, did their Tenant ID change or get recreated? Sometimes SSO provisioning can result in a new tenant being created, which would mean the old tenant ID in your filter is still valid but the new logins are going through a different tenant. You'd see the events in Descope's audit log under the new tenant ID, but the webhook filter wouldn't know about it yet. Could you share your project ID and the tenant ID so I can check logs as well ?

There are I saw the logins in the audit trail

The connector is running every ~7-8 minutes and completing successfully, but there are zero HTTP delivery calls to Coralogix — meaning every single run finds 0 matching

LoginSucceed

events to send. This is odd given you can see them in the audit trail. A few likely causes: 1. Cursor issue — If the connector was reconfigured (e.g. the

LoginSucceed

filter was added or the connector was edited), the internal cursor may have been reset to "now", meaning it only picks up events going forward from that reconfiguration point. Any

LoginSucceed

events before that moment won't be re-streamed. 2. Filter mismatch — The action filter is case-sensitive. Make sure the filter is set to exactly

LoginSucceed

(no spaces, correct casing). Quick test to isolate the issue: Temporarily remove the

LoginSucceed

action filter from the connector (stream all events) and check if anything starts flowing to Coralogix. If events appear → the filter is blocking them. If nothing appears → there may be a cursor or connector config issue. If the cursor was reset and events are being missed, that's something we'd need to investigate on our side — let me know the outcome of the test and we can go from there!

I see logins in coralogix just not for their tenant

Got it — since other tenants are flowing fine, the connector is healthy. The issue is likely that the

LoginSucceed

events for this client aren't being tagged with tenant

c58ebe00-3c64-4fd5-81f5-a08abcb9b7a2

after the Okta SSO setup. Can you open one of those

LoginSucceed

events in the Descope audit trail and check the Tenant field? If it's empty or shows a different ID, the SSO login isn't scoped to the expected tenant — which would explain why it's not showing up in Coralogix.