CrowdStrike API Data Connector (via Codeless Connector Framework) (Preview)

You're not alone on this one. The CrowdStrikeDetections table not ingesting is a known issue, and it's not a misconfiguration on your end.

CrowdStrike decommissioned the /detects/queries/detects/v1 API endpoint that the Codeless Connector Framework (CCP) connector was relying on to pull detection data. The result is a 404 error on every ingestion attempt for detections, while Alerts and Hosts continue to work fine because they use different endpoints.

You can confirm this is hitting your environment by running this KQL:

SentinelHealth | where SentinelResourceName contains "ApiPolling-CrowdStrikeDetections" | project TimeGenerated, SentinelResourceName, Status, Description, Reason | sort by TimeGenerated

If you see failure entries referencing the decommissioned endpoint, that's your confirmation.

This is actively tracked on GitHub: https://github.com/Azure/Azure-Sentinel/issues/12900. It's been escalated, but as of now the connector hasn't been updated to use the replacement API endpoint from CrowdStrike.

What you can do in the meantime:

• CrowdStrike Alerts table is your best substitute. Alerts and Detections have significant overlap in the data they surface. You won't get the exact same schema, but for most SOC workflows it covers the critical fields.
• Open a support ticket with Microsoft. The more customers that report this, the faster it moves. Reference the GitHub issue number.
• Consider the Falcon Data Replicator (FDR) connector if you need deeper telemetry. It uses a different ingestion path entirely and isn't affected by this API deprecation. The tradeoff is it requires more setup and uses different tables.

Worth noting there's also a broader issue with the CCP connector. The recent update introduced new table schemas that broke some existing analytics rules and queries in the Content Hub (https://github.com/azure/azure-sentinel/issues/13121). So if you're building detections around CrowdStrike data, double check your queries against the current schema.

Bottom line: this is a CrowdStrike API change that Microsoft's connector team needs to catch up with. Not something you can fix from your side.

Please mark as solution, if you find the answer helpful. This will assist others in the community who encounter a similar issue, enabling them to quickly find the solution and benefit from the guidance provided.