Transitioning from the HTTP Data Collector API to the Log Ingestion API…What does it mean for me?

 

This article is co-authored by Andrea Fisher, Brian Delaney, and Jon Shectman (Microsoft Customer Success Unit).

Many customers have recently received an email sharing the information that the HTTP Data Collector API will be retired on September 14, 2026. What exactly does that mean for you? Either you have deployed a built-in Microsoft Sentinel Data Connector that is using the HTTP Data Collector API or you have configured a custom connector of your own that uses the API. In this blog, we’ll explain why you got (or will receive) this notification, what’s at stake, and what actions you need to take.

But first, what is the HTTP Data Collector API Anyway?

The HTTP Data Collector API is nothing more than a set of rules and protocols governing (you guessed it!) data collection – in this case to Azure Monitor (a “back end” for Microsoft Sentinel). This API has been deprecated in favor of a newer, improved API, the Azure Monitor Logs Ingestion API. Here is a copy of the email:

Figure 1: Copy of the Email

What actions should I take?

As you can see, the Account Information section only lists the Subscription name and ID that are calling the old API. It doesn’t state how your organization is calling it. Below are three possibilities.

1. Do you have a custom application that you built or licensed?
2. Do you have any custom data connectors (likely built as either Azure Functions or codeless connectors)?
3. You have a data connector from the in-product Content Hub, provided by Microsoft or one of our partner ISVs – that will be rewritten prior to the API deprecation date.

It’s also possible that you could be using more than one of the above methods in your workspace or in more than one workspace in your subscription.

There are several steps you can take to start discovering your usage of this deprecated API. In your Log Analytics workspace, navigate to Settings, then Tables and examine the Type column. Any table built with data from the deprecated API will be of type Custom table (classic).

 

Figure 2: Custom table (classic)

Remember, some of these tables may not be in use anymore; there are many ways to identify tables that are in active use. One way is with a simple query - as in this example:

InformationProtectionLogs_CL
| where TimeGenerated > ago(90d)

You could also examine the Usage and estimated costs chart in Log Analytics, or if you want to check regularly over time you could set up a log search alert rule.

Now let’s examine built-in data connectors that use the deprecated API. Generally, they specify their usage in the details:

Figure 3: Built-in Connector using the Deprecated API

 

To remediate:

• If you discover a custom application or data connector, you will need to follow these steps to transition to the Logs Ingestion API before the retirement date. We recommend that you do not wait but start the process early to give your organization time to thoroughly test and migrate all applications and connectors.
• For built-in data connectors, you’ll need to watch the Content Hub for updates and guidance as shown in these two screenshots:

Figure 4: Content Hub Data Connector UpdatesFigure 5: Content Hub Data Connector Guidance

Advantages of the Azure Monitor Logs Ingestion API

There are numerous advantages to using the new API:

1. It supports transformations, which enable you to modify the data before it's ingested into the destination table, including filtering and data manipulation.
2. It allows you send data to supported Azure tables or to custom tables that you create. You can extend the schema of Azure tables with custom columns to accept additional data.
3. It lets you send data to multiple destinations.
4. Last but certainly not least (we are security practitioners after all): it allows for granular role-based access controls (RBAC) to limit the ability to ingest data by data collection rule and identity.

In Summary

The transition from the HTTP Data Collector API to the Azure Monitor Logs Ingestion API is crucial for maintaining data ingestion functionality and security. The new API offers several advantages, including secure OAuth-based authentication, the ability to filter and transform data during ingestion, and granular RBAC. Organizations should proactively transition to the new API before the retirement date of September 14, 2026.