Count mismatch for import indictors api.

Question

Count mismatch for import indictors api.

Rushi Satani 0

I am trying to call https://dotnet.territoriali.olinfo.it/en-us/defender-endpoint/api/import-ti-indicators api using azure function. However i have noticed that there is a mismatch among the count in response.

Basically i am sending X amount of indicators through API but I am getting response for Y indicators.

This issue isnt replicated every time however it does occur from time to time.

Siddhesh Desai 5,850 Reputation points Microsoft External Staff Moderator

2026-03-02T07:48:07.7033333+00:00
Hi @Rushi Satani

Thank you for reaching out to Microsoft Q&A.

When calling the Import TI Indicators API from an Azure Function, a mismatch between the number of indicators sent in the request (X) and the number of indicators returned in the response (Y) can occur intermittently due to the way the service processes indicator batches. This API is designed to submit or update indicators rather than guarantee a one-to-one response for every indicator in the request. As a result, indicators may be deduplicated, merged, partially processed, or filtered internally before a response is generated. This behavior is expected under certain conditions such as duplicate indicators, existing indicators being updated, tenant-level indicator limits, throttling, or validation failures. Because these conditions depend on the data being sent and the runtime state of the tenant, the issue may not reproduce consistently every time.

Refer below points to resolve this issue or as a workaround:

1. Deduplication of indicators in request payload If multiple indicators in the same request have the same combination of indicatorType and indicatorValue, Microsoft Defender for Endpoint deduplicates them internally. In such cases, only one result is returned in the response for those duplicates, which reduces the overall response count. Workaround: Deduplicate indicators on the client side before calling the API to ensure each indicator is unique within the batch.

2. Existing indicators are updated, not re-created The API treats the import operation as an upsert (submit or update). If an indicator already exists in the tenant, the API updates it instead of creating a new entry. This may result in fewer response items than the number of indicators sent. Workaround: Do not rely on response count for validation. Instead, track indicators using indicatorType + indicatorValue and treat the operation as idempotent.

3. Tenant active indicator limit (15,000 indicators) Microsoft Defender for Endpoint enforces a maximum of 15,000 active indicators per tenant. When this limit is reached or nearly reached, new indicators may not be fully processed, even though the API returns HTTP 200 (OK). Workaround: Periodically review and expire unused indicators to stay within the tenant limit.

4. Throttling and partial batch processing The API has a rate limit of 30 calls per minute and a maximum batch size of 500 indicators per request. Under high concurrency (common with Azure Functions), partial processing can occur without returning explicit failures. Workaround: Implement batching (≤500 indicators), apply client-side throttling, and avoid parallel executions against this API.

5. Early validation filtering of invalid indicators Indicators with unsupported formats (for example, CIDR notation for IPs), invalid values, or incorrect expiration times may be rejected during early validation and not included in the response array. Workaround: Validate indicator formats and required fields before submitting the request.

6. Recommended reconciliation approaches The API response should be treated as best effort rather than authoritative by count. Workaround:

Log all indicatorValue entries sent in the request

Compare them with the indicator values returned in the response

Track and handle missing indicators explicitly in your application logic
Praveen Kumar Gudipudi 2,280 Reputation points Microsoft External Staff Moderator

2026-04-06T08:22:43.78+00:00

Hi @Rushi Satani,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

1 answer

Your answer

Praveen Kumar Gudipudi 2,280 Reputation points Microsoft External Staff Moderator

2026-04-06T08:22:43.78+00:00

Hi @Rushi Satani,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Answer 1

The behavior matches known indicator and counting limitations rather than an Azure Functions issue.

Key points relevant to the mismatch:

Tenant-wide indicator limit
Defender for Endpoint enforces a hard limit of 15,000 indicators per tenant. When this limit is approached or reached, not all submitted indicators can be stored. This can cause the API response to show fewer successfully processed indicators than were sent.
Different enforcement types and behavior
Indicators use updated enforcement types (audit, block and remediate, allow, block and warn). These do not change the raw count of indicators, but they can affect how indicators are processed and surfaced (for example, whether alerts are generated). If the same indicator (same key fields) is submitted multiple times with different actions, it may be updated instead of counted as a new indicator, which can also make the “processed” count appear lower than the number sent.
Partner / threat-intelligence integration behavior
When indicators come from threat-intelligence providers or partner integrations, Defender for Endpoint correlates and may remediate based on matches. If the same indicator already exists (for example, from a previous import or a partner feed), a new import may update the existing record rather than add a new one, again causing a mismatch between “sent” and “newly created” indicators.
Intermittent nature
The fact that the mismatch is intermittent is consistent with:
- Periodically hitting or nearing the 15,000-indicator limit.
- Re-sending indicators that already exist (updates vs. inserts) only in some batches.

To troubleshoot concretely:

Check current indicator count
Use the Microsoft Graph Security threat intelligence profile indicator count cmdlets to see how many indicators currently exist:
- Get-MgSecurityThreatIntelligenceProfileIndicatorCount (v1.0)
- or Get-MgBetaSecurityThreatIntelligenceProfileIndicatorCount (beta)
If the count is close to 15,000, prune old or unneeded indicators before importing new ones.
Verify duplicates vs. new indicators
Compare a sample of indicators from a batch where the mismatch occurs against existing indicators (same value, type, and scope). If they already exist, the API may be updating them instead of creating new entries, which explains a lower “created” count.
Monitor per-batch results
Log the API response from each Azure Function execution and compare:
- Number of indicators sent in the request
- Number reported as created/updated/failed in the response
This helps distinguish between:
- Indicators rejected due to tenant limits
- Indicators treated as updates
- Actual failures (which should be visible in the response details)

If the current indicator count is well below 15,000 and the response does not classify the “missing” indicators as failures or updates, capture a failing batch (request and response metadata, excluding secrets) and open a support case, as that would fall outside documented behavior.

References:

Share via

Count mismatch for import indictors api.

1 answer

Your answer