---
schema_version: "1"
id: 9c7de2600c5cb6c6a49c252e5aa1943e0f71ca47c9f0f26f621fe33e7550f7b1
title: Best Practices for Investigating API Request Anomalies
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/xcloud/264-0-0/real_time_em_threat_detection_api_bestpractices.md
canonical_url: https://help.salesforce.com/s/articleView?id=xcloud.real_time_em_threat_detection_api_bestpractices.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: 28256595302de78a949bec2ab584b21c97ec508358a7b8b86220e1cbf810e574
description: Keep these tips and best practices in mind when you investigate unusual user behavior. Find the information you require to make a well-informed evaluation of your data’s safety.
products:
  - Salesforce Platform
  - Cross Cloud
release: "264"
---
# Best Practices for Investigating API Request Anomalies

Keep these tips and best practices in mind when you investigate unusual user behavior. Find the information you require to make a well-informed evaluation of your data’s safety.

### Required Editions

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small edition">
      <colgroup>
        <col>
      </colgroup>
      <tbody>
        <tr class="">
          <td class="slds-cell-wrap" style="vertical-align:top;">Available in both Salesforce Classic (not available in all orgs) and Lightning
            Experience.</td>

        </tr>
        <tr class="">
          <td class="slds-cell-wrap" style="vertical-align:top;">
            <p>Available in: <strong>Enterprise</strong>, <strong>Unlimited</strong>, and <strong>Developer</strong>
              Editions</p>
            <p style="margin-bottom:0;">Requires Salesforce Shield or Salesforce Event Monitoring add-on
              subscriptions.</p>
          </td>

        </tr>
      </tbody>
    </table> <table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small ">
      <colgroup>
        <col style="width:25%">
        <col style="width:75%">
      </colgroup>
      <thead class="slds-text-title_caps ">
        <tr class="">
          <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d193959e69">Best Practice</th>
          <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d193959e72">Description</th>
        </tr>
      </thead>
      <tbody>
        <tr class="">
          <td data-label="Best Practice" class="slds-cell-wrap" style="vertical-align:top;" headers="d193959e69 ">Identify the involved user.</td>

          <td data-label="Description" class="slds-cell-wrap" style="vertical-align:top;" headers="d193959e72 ">
            <p>Keeping customer privacy in mind, we can't access customer data or any data inside the
              reports. As a result, we can provide only the user ID of the user who generated the report
              that is marked as an anomaly. Use this user ID to locate the username and other details
              about the person associated with the detection event. </p>
            <p style="margin-bottom:0;">Field:
              <samp class="parmname">ApiAnomalyEvent.UserId</samp>
            </p>
          </td>

        </tr>
        <tr class="">
          <td data-label="Best Practice" class="slds-cell-wrap" style="vertical-align:top;" headers="d193959e69 ">Use the timestamp.</td>

          <td data-label="Description" class="slds-cell-wrap" style="vertical-align:top;" headers="d193959e72 ">
            <p>Our detection model already considers various features derived from the timestamp to
              determine report generation activity as anomalous or not. You can use this timestamp to
              narrow down the set of events you must review. You can also determine if the time of
              report generation was unusual for the user who generated the report. </p>
            <p style="margin-bottom:0;">Field:
              <samp class="parmname">ApiAnomalyEvent.EventDate</samp>
            </p>
          </td>

        </tr>
        <tr class="">
          <td data-label="Best Practice" class="slds-cell-wrap" style="vertical-align:top;" headers="d193959e69 ">Use contributing factors as a guide.</td>

          <td data-label="Description" class="slds-cell-wrap" style="vertical-align:top;" headers="d193959e72 ">
            <p>The contributing factors JSON output shows the features in descending order of
              contribution. As you start your investigation into the event logs, keep an eye out for the
              top contributing features. If these features look unusual, they can provide more evidence
              that confirms the anomaly or even indicate a possible data breach. </p>
            <p style="margin-bottom:0;">Field:
              <samp class="parmname">ApiAnomalyEvent.SecurityEventData</samp>
            </p>
          </td>

        </tr>
        <tr class="">
          <td data-label="Best Practice" class="slds-cell-wrap" style="vertical-align:top;" headers="d193959e69 ">Consider the anomaly in the context of the user's typical behavior.</td>

          <td data-label="Description" class="slds-cell-wrap" style="vertical-align:top;" headers="d193959e72 ">
            <p>Using the ReportAnomalyEvent field values, try to determine whether the user activity
              within the detection event is typical for the user. For example, consider if it's typical
              for a user to generate a report from the IP address provided. </p>
            <p style="margin-bottom:0;">Field:
              <samp class="parmname">ApiAnomalyEvent.SourceIp</samp>
            </p>
          </td>

        </tr>
        <tr class="">
          <td data-label="Best Practice" class="slds-cell-wrap" style="vertical-align:top;" headers="d193959e69 ">Consider the size of the report.</td>

          <td data-label="Description" class="slds-cell-wrap" style="vertical-align:top;" headers="d193959e72 ">
            <p>We consider the size of the report to determine if the report generation was anomalous.
              A user generating a larger report than usual can indicate an unauthorized data export
              attempt. For example, an attacker obtained unauthorized access to the user's account and
              exfiltrate as much data as possible before losing access. Or it could mean that a
              disgruntled employee is exfiltrating data for use beyond the needs of the employer.
            </p>
            <p style="margin-bottom:0;">Field: <samp class="parmname">ApiAnomalyEvent.SecurityEventData</samp> (specifically the
              rowCount feature name)</p>
          </td>

        </tr>
        <tr class="">
          <td data-label="Best Practice" class="slds-cell-wrap" style="vertical-align:top;" headers="d193959e69 ">Not all anomalies are malicious.</td>

          <td data-label="Description" class="slds-cell-wrap" style="vertical-align:top;" headers="d193959e72 ">While some anomalies can indicate a malicious intent, other anomalies can be legitimate
            but unusual. Our detection model can produce detection events that are unusual but not
            malicious. For example, if an employee gets promoted to a new role and starts generating
            larger reports, our model can flag this behavior as anomalous.</td>

        </tr>
      </tbody>
    </table>

#### See Also

- [_Platform Events Developer Guide_: ApiAnomalyEvent](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/sforce_api_objects_apianomalyevent.htm?q=API%20Anomaly)
- [_Platform Events Developer Guide_: ApiEvent](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/sforce_api_objects_apievent.htm)