Why Salesforce API Breaches Often Go Undetected Despite ‘Normal’ Usage

In my sister article, An Admin’s Guide to Better Salesforce API Usage Monitoring, we covered the foundations of API monitoring – understanding your limits, setting up notifications, reading event logs, and building governance practices. That knowledge helps you answer “how much API capacity are we using?” It’s an important question, but not the only one that matters. 

In this article, we’ll explore how to detect *anomalies* – unusual patterns in your API traffic that might indicate security threats, failing integrations, or shadow IT, even when usage stays well within your limits. You will learn the five categories of API anomalies, the algorithms that can detect them, and how to build (or simply install) a system that transforms raw events into actionable alerts.

The Alert That Tells You Nothing

Picture this – it’s Monday, 8 AM. Your inbox says: “API usage reached 85% of your daily limit” on Saturday, when nobody was supposed to be working.

If you read my first article, then you should know the drill. You open System Overview and check the seven-day report. You downloaded yesterday’s API Total Usage CSV and pieced together that an integration user made a lot of calls. Case closed? Not quite.

Here is the uncomfortable truth: the most dangerous API activity often stays well within your limits.

So it’s important to consider these scenarios that would never trigger a usage alert:

• A compromised integration credential is exfiltrating data at the same volume as normal operations, just to different objects.
• A new IP address in Eastern Europe is making calls through a legitimate connected app.
• Your ETL job is running at 7 PM instead of 3 AM, at the same volume as always.
• An error rate that has quietly climbed from 2% to 18% over the past week.

None of these would breach your Daily API Request Limit or fire your 80% threshold notification. Yet each represents a real risk: credential theft, unauthorized access, hijacked automation, or a failing integration about to break production.

The gap is this: traditional API monitoring answers “how much?” Anomaly detection answers “what changed?” and “should I worry?”

We previously covered the foundations: understanding limits, enabling notifications, reading event logs, and establishing governance practices. That work is essential, but it is really table stakes.

This article goes deeper. We will explore the types of anomalies that hide in plain sight, the algorithms that can detect them, and how to build – or simply install – a system that turns raw API events into actionable intelligence.

The goal is simple: when your CEO asks “what happened?”, you should be able to tell a story, not just quote a percentage.

What Do Your Event Logs Actually Contain?

Before we discuss anomaly detection, let us revisit the raw material: your API Total Usage event logs.

As covered in my first article, these logs are available through Salesforce’s free Event Monitoring feature. Each row represents a single API call. The key fields include:

What Do Most Admins Do?

The typical workflow looks like this:

1. Something goes wrong (or an alert fires).
2. Download the CSV from Event Log Browser.
3. Open in Excel, pivot by user or app.
4. Find the culprit, move on.

This is a reactive investigation, which works when you already know something is wrong, but fails at catching problems before they cause damage.

What Becomes Possible With Analysis

The same data, analyzed systematically, can answer much harder questions:

• Is this user behaving normally? Compare today’s activity to their median over the past 30 days.
• Is this app running at the right time? Check whether it has ever been active at this hour before.
• Have we seen this IP before? Cross-reference against all historical IPs for this org.
• Is this error rate concerning? Compare today’s 4xx/5xx ratio to the baseline.

The data is already there. What most orgs lack is the analysis layer – the infrastructure that transforms raw events into baselines, and baselines into anomaly signals. The rest of this article is about building that layer.

The Five Categories of API Anomalies

Not all anomalies are created equal. To design effective detection, it helps to think in categories. Each type of anomaly has different characteristics, risks, and detection approaches.

1. Volume Anomalies

What it is: A sudden spike in traffic from a specific user, IP address, or connected app.

Examples:

• An integration user who normally makes 5,000 calls per day suddenly makes 50,000.
• A previously dormant connected app suddenly begins making thousands of requests.
• Overall API traffic doubles on a day when no deployment or data migration was scheduled.

Why it matters:

Volume spikes can indicate data exfiltration (someone downloading your entire Account table), runaway automation (a loop that forgot to terminate), or credential abuse (a stolen token being used at scale).

Detection approach:

Compare today’s volume against a historical baseline – typically the median or mean over the past 14 to 30 days. Flag when the current value exceeds a threshold, such as two times the median or mean + three standard deviations.

2. Temporal Anomalies

What it is: Activity occurring at unusual times – hours, days, or patterns that deviate from established behavior.

Examples:

• Your nightly ETL job, which always runs at 3 AM, suddenly executes at 7 AM.
• A user who has never worked weekends starts making API calls on Saturday afternoon.
• A connected app that only runs during business hours is now active at midnight.

Why it matters:

Temporal shifts often indicate hijacked credentials. An attacker who gains access to an integration token does not know (or care) about your operational schedule. They access data when it is convenient for them, not when your systems normally run.

Detection approach:

Build per-hour baselines for each user and app. Flag activity at hours when the baseline is zero (“never seen at this hour before”) or significantly higher than the baseline for that specific hour.

3. Geographic and Identity Anomalies

What it is: Access from new or unexpected sources – IP addresses, countries, or connected apps that have never been seen before.

Examples:

• API calls arrive from an IP address in a country where you have no offices, vendors, or customers.
• A new connected app ID appears in your logs that nobody recognizes.
• An IP address you have never seen before starts making significant API calls.

Why it matters:

New identities are inherently suspicious. A legitimate integration does not spontaneously appear from a new country. Shadow IT, credential theft, and targeted attacks all manifest as “first-time” appearances in your logs.

Detection approach:

Maintain sets of “seen before” values, such as IPs, countries, and connected app IDs. Flag anything new that crosses a minimum activity threshold (to avoid noise from one-off requests). Enrich IP addresses with geolocation and ASN data to provide context.

4. Error Anomalies

What it is: An increase in API errors – 4xx client errors or 5xx server errors – beyond normal levels.

Examples:

• Error rate jumps from a baseline of 2% to 25% in a single day.
• A specific user starts receiving 401 Unauthorized responses repeatedly.
• A connected app begins hitting 429 Too Many Requests errors.

Why it matters:

Error spikes can indicate security threats like credential stuffing attacks (many 401s from varied IPs) or brute force attempts. But they often reveal operational issues too: an integration using a refresh token that expired, credentials that were rotated without updating the connected system, permission sets that changed, or an endpoint that was deprecated. 

Either way, elevated error rates deserve investigation before they cause data inconsistency or integration failures.

Detection approach:

Calculate the error rate (errors / total calls) for each day, user, or app. Compare against the historical baseline. Flag when the rate exceeds baseline by a defined threshold (e.g., +10 percentage points).

5. Behavioral and Sequence Anomalies

What it is: Unusual patterns in what is accessed or how the API is used, beyond simple volume or timing.

Examples:

• A user who normally queries Account and Contact suddenly starts accessing Custom_Sensitive_Object__c.
• API calls arrive in an unusual sequence – metadata queries followed by bulk exports (a classic reconnaissance pattern).
• Request parameters or payload sizes deviate significantly from normal.

Why it matters:

Sophisticated attackers stay within volume limits and operate during business hours. What gives them away is what they access and how they navigate your data model. These patterns are the hardest to detect but often the most revealing.

Detection approach:

This is where simple rules reach their limits. Detecting behavioral anomalies typically requires tracking entity access patterns per user, modeling call sequences, or using machine learning to identify outliers in high-dimensional data. Most orgs do not implement this today – it represents the frontier of API security monitoring.

Anomaly Categories at a Glance

Most orgs should start with volume, temporal, geographic, and error detection. These categories cover the majority of real-world incidents and can be implemented with straightforward statistical methods.

How Can You Detect Anomalies?

Knowing what to look for is half the battle. The other half is choosing how to detect it. This section outlines three tiers of detection approaches, from practical and proven to cutting-edge.

1. Statistical and Baseline Models

The approach:

Calculate simple statistics over a rolling historical window, typically 14 to 30 days. Common metrics include:

• Median: The middle value, robust against outliers.
• Mean and standard deviation: For normally distributed data.
• Percentiles: P75, P90, P95 for understanding the range of normal.

Flag an anomaly when today’s value exceeds a threshold:

• Volume > 2× median.
• Volume > mean + 3σ (three standard deviations).
• Error rate > baseline + 10 percentage points.

Why it works:

These methods are battle-tested. They can begin detecting anomalies with as few as 5-7 data points, though baselines become more reliable with 14-30 days of history. 

They run fast and produce results that are easy to explain. When you tell a stakeholder, “this user made 3.2x their normal daily volume,” they understand immediately.

Real-world application:

• Volume spike detection: Compare today’s call count per user or app against their historical median.
• Temporal detection: Build separate baselines for each hour of the day; flag activity where the baseline is zero.
• Error rate monitoring: Track the ratio of 4xx/5xx responses and compare to baseline.

Best for: Volume, temporal, and error anomalies. This is where most orgs should start.

2. Rule-Based and Set-Based Detection

The approach:

Instead of comparing numbers, track presence. Maintain sets of values that have been seen before:

• All IP addresses observed in the last 30 days.
• All countries from which API calls have originated.
• All connected app IDs that have accessed this org.

Flag anything new that crosses a minimum activity threshold. A single request from a new IP might be noise; 50 requests from a new IP in a new country are worth investigating.

Why it works:

Novelty detection requires no training period and produces high-signal alerts. A legitimate integration does not appear from nowhere. If you have never seen traffic from Romania and suddenly you do, that is information worth having, regardless of volume.

Enrichment matters:

Raw IP addresses are hard to reason about. Enriching them with geolocation (country, city) and ASN data (the network operator) transforms “new IP 185.220.101.42” into “new IP from Germany, operated by a known VPN provider.” Context changes the conversation.

Best for: Geographic and identity anomalies. Low implementation complexity, high value.

3. Unsupervised Machine Learning

The approach:

Move beyond single-variable thresholds. Use algorithms that can model normal behavior across multiple dimensions and flag points that do not fit:

• Isolation Forest: Efficient at finding outliers in high-dimensional data.
• DBSCAN: Density-based clustering that naturally identifies points outside clusters.
• One-Class SVM: Learns a boundary around “normal” and flags anything outside.

Why it works:

ML models can discover patterns that humans would not think to specify. A user who makes slightly elevated calls, at a slightly unusual hour, accessing slightly different objects. Each dimension might be within normal bounds, but the combination is anomalous. ML can catch these compound signals.

Considerations:

• Requires more data to train effectively.
• Results can be harder to explain (“the model flagged this”).
• False positives require tuning and feedback loops.
• Compute and infrastructure requirements increase.

Best for: Behavioral anomalies at scale, especially when you have exhausted what simple statistics can catch.

4. Deep Learning Models

The approach:

Apply neural networks to learn complex patterns in sequential data:

• Autoencoders: Learn a compressed representation of “normal” API behavior; flag events with high reconstruction error.
• LSTMs and Transformers: Model temporal dependencies in sequences of API calls; detect when a sequence deviates from learned patterns.

Why it works:

Deep learning excels at sequence and behavioral anomalies – the hardest category to detect. 

An attacker performing reconnaissance (metadata query → schema exploration → targeted export) follows a sequence that, individually, looks innocent. A well-trained model can recognize the pattern.

Considerations:

• Significant investment in data, compute, and expertise.
• Often overkill for a typical Salesforce org.
• Better suited for platform vendors securing thousands of orgs, or very large enterprises with dedicated security teams.

Honest assessment:

Most Salesforce organizations will get 80% of the value from statistical and set-based approaches. Machine learning and deep learning are for when you have maxed out simpler methods and have the resources to invest in more sophisticated detection.

How Should You Choose Your Approach?

Start simple. A well-implemented baseline model will catch the majority of real incidents. Add complexity only when you have evidence that simpler methods are missing important signals.

How Can You Build an External System?

For architects and technical leaders considering a build approach, this section outlines what an external anomaly detection system looks like and why external processing is often necessary.

1. Why External?

Salesforce’s platform has constraints that make sophisticated anomaly detection difficult to implement natively:

• Limited event log retention: API Total Usage is part of Salesforce’s free Event Monitoring feature; you just need to enable it in Setup. However, log files are generated daily (covering the previous day’s activity) and remain available for download for only 24 hours. With Shield Event Monitoring, retention extends to 30 days, but building reliable baselines still requires storing data externally where you control the retention period.
• Apex governor limits: Complex aggregations, statistical calculations, and comparisons across millions of rows exceed what Apex can efficiently process. A baseline calculation that takes 50ms in PostgreSQL might timeout in Apex.
• Multi-org visibility: Many organizations manage multiple Salesforce orgs – production, sandboxes, and acquired companies. An external system can provide unified visibility across all of them.
• Historical analysis: Understanding trends, investigating past incidents, and comparing year-over-year patterns requires persistent storage that outlives Salesforce’s native retention.

2. Cloud Platform Options

You can build an anomaly detection pipeline on any major cloud platform:

• AWS: Lambda for serverless functions, Step Functions for orchestration, S3 for storage, RDS (PostgreSQL) for the database.
• Google Cloud: Cloud Functions, Cloud Workflows, Cloud Storage, Cloud SQL.
• Microsoft Azure: Azure Functions, Logic Apps, Blob Storage, Azure SQL.
• Heroku: A natural fit for teams already in the Salesforce ecosystem, with Postgres add-ons and scheduled dynos.

The architectural pattern remains similar regardless of platform. Choose based on your team’s existing expertise and your organization’s cloud strategy.

3. High-Level Architecture

A typical pipeline consists of four stages:

1. Data Ingestion

A scheduled job (daily, typically) connects to each Salesforce org, downloads the API Total Usage event log files, and stores them in cloud storage. This creates a durable archive of raw events, organized by org and date.

2. Processing and Aggregation

When a new file arrives, a processing function:

• Parses the CSV and inserts rows into a relational database.
• Extracts key fields from the raw payload (user, IP, app, status code, timestamp).
• Creates aggregates – daily totals per user, daily totals per app, hourly breakdowns.

Aggregates are the foundation for efficient baseline calculations. Querying “sum of calls per user per day for the last 30 days” is fast when the data is pre-aggregated.

A key design consideration: make processing idempotent. If a file is processed twice (due to retries or errors), the system should produce the same result. This typically means using upsert operations keyed on org + date + unique identifiers rather than simple inserts.

3. Baseline Calculation

A separate function reads the aggregates for the past 30 days and calculates baselines:

• Median call count per user per day.
• Median call count per app per hour.
• Sets of known IPs and countries.

These baselines are stored in the database, ready for comparison during anomaly detection.

4. Anomaly Detection

The analyzer runs after baselines are updated. It:

• Compares today’s aggregates against baselines.
• Runs each detector (volume spike, temporal anomaly, new IP, error rate, etc.).
• Records detected anomalies with severity, score, and links to evidence.
• Syncs anomalies back to Salesforce as custom objects (Anomaly__c) for visibility in the org.

Results and Notifications

Detected anomalies flow back into Salesforce, where they can trigger:

• In-app notifications for admins.
• Email alerts.
• Slack messages via connected integrations.
• Custom automation via Flow or Apex triggers.

The key is that the investigation occurs where your team already works – inside Salesforce – while the heavy computation takes place externally.Design for alerts, not dashboards. Nobody wants another screen to check every morning.

The goal of an anomaly detection system is to be silent on calm days and loud when something needs attention. Configure notifications to reach your team where they already are, such as Slack, email, or in-app alerts, so anomalies find you, rather than requiring you to go looking for them.

The Easier Path:  Install Instead of Build

Not every team wants to own the operational overhead of an external pipeline: storage, scheduling, data processing, baseline computation, alert routing, and ongoing tuning. In many orgs, the pragmatic alternative is to deploy a managed solution that already implements the core pattern: retain the logs, compute baselines, run detectors, and surface findings where admins work.

One option is sAPIm (Simple API Monitor for Salesforce), a free managed package that applies the same concepts described in this article, baseline-based anomaly detection over API Total Usage events, without requiring you to build and operate the ingestion and analytics stack yourself. In practical terms, solutions in this category typically provide:

• API usage history beyond native retention, enabling stable baselines and retrospective investigations.
• Automatic baselines by user, connected app, and time-of-day patterns.
• Detectors for common anomaly classes: volume spikes, unusual timing, new sources such as IP/country/app identifiers, and elevated error rates.
• Human-readable context, for example, mapping IDs to friendly labels where possible.
• Notification hooks, such as email or in-app alerts, so anomalies surface without requiring a separate dashboard.

Note: I’m affiliated with sAPIm, and the package is free. I’m mentioning it as a concrete reference implementation of the “install instead of build” approach described above, not as a blanket recommendation. The real decision is still whether you want to operate the pipeline yourself. Building gives maximum control and customization, while installing a package reduces infrastructure and maintenance work. Choose based on your team’s capacity to own ingestion, storage/retention, detector tuning, and alerting over time.

7. Practical Checklist: What to Do Now

Reading about anomaly detection is one thing, but implementing it is another. Here is a staged approach based on where your organization is today.

If you are just starting, focus on these foundations covered in part one:

• Enable Event Monitoring in Setup → Security → Event Monitoring Settings.
• Download one API Total Usage CSV from Event Log Browser and explore it in Excel or Google Sheets.
• Identify your top 5 integration users and the connected apps they use.
• Set up API Usage Notifications at 50%, 80%, and 90% thresholds.
• Document your integrations in a simple catalog: app name, owner, expected schedule, typical volume.

This groundwork makes everything else possible. If you are ready for anomaly detection, it’s time to move beyond limits and totals:

• Decide if you’re building or buying: Consider your team’s cloud platform expertise, available time, and appetite for ongoing maintenance.
• If building: Start with the simplest detectors – overall volume spike and new IP detection. Add complexity incrementally.
• If installing: Install sAPIm or a similar tool in a sandbox first. Connect it to your org and review the initial baseline period.
• Establish notification channels: Anomalies that nobody sees provide no value. Route alerts to email, Slack, or in-app notifications.
• Designate an owner: Someone needs to review anomalies and decide whether they warrant investigation.

If you already have detection in place, refine and expand by:

• Review coverage: Are you detecting all five anomaly categories? Most orgs have volume and error detection but lack temporal and geographic coverage.
• Tune thresholds: Too many false positives cause alert fatigue. Too few means you miss real incidents. Either way, adjust based on your experience.
• Track response times: Consider how quickly anomalies get reviewed and how often they lead to real action.

Plan for new detectors: Behavioral and sequence anomalies are the frontier. Consider whether ML-based approaches make sense for your scale.

Final Thoughts

Organizations that suffer API-related breaches often have perfectly normal usage volumes. They have alerts configured. They check System Overview regularly. What they lack is the ability to answer: Is this behavior normal for this user, this app, at this time, from this location?

Traditional monitoring answers “how much?” Anomaly detection answers “what changed?” The difference is the difference between a percentage and a story.

When your CEO asks, “What happened Saturday?”, you should be able to say:

“”At 2:32 PM, our Marketing Automation integration started making calls from a new IP address in Germany. That IP had never accessed our org before. Volume was normal, but the timing and location were anomalous. We flagged it, investigated, found the vendor had spun up a new data center, and confirmed it was legitimate.””

This is what anomaly detection provides. Start with the foundations from my first article; layer anomaly detection on top, and when the next Monday morning alert arrives, be ready to tell the story.