Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

Login History is the only complete list of things that authenticate to your org, and almost nobody reads it as one. Four columns do the work: Application, API Type, API Version and Source IP. Sort by those instead of by time and the report stops being a log and starts being an inventory of every integration you have, including the ones nobody wrote down.

Where it lives and how far back it goes

Setup, then Login History. The list view covers roughly six months and lets you download a CSV. The same data is the LoginHistory object, which is queryable, and that is the better route once you want to do anything but scroll:

sf data query --target-org prod --query "SELECT LoginTime, UserId, Application, ApiType, \
ApiVersion, SourceIp, Status, LoginType FROM LoginHistory \
WHERE LoginTime = LAST_N_DAYS:30 ORDER BY LoginTime DESC" --result-format csv > logins.csv

Pull it into a spreadsheet and pivot on Application, API Type and API Version. Thirty days catches every weekly job. Go to ninety if you have monthly processes.

The columns that matter

Application. A browser login says Browser. Anything using OAuth names the connected app or external client app. Older integrations may say something generic, or nothing useful. This column is your inventory: every distinct value is a system holding credentials to your org.

API Type. Which interface was used: Partner or Enterprise SOAP, REST, Bulk, Metadata, Tooling. A client using the Metadata or Tooling API is reading or writing configuration, a very different risk profile from one reading Accounts. An unexpected Metadata API caller is worth stopping for.

API Version. The single most actionable column. Salesforce retires old API versions in batches, and a client still calling a version from several years ago has a scheduled outage waiting for it. Sort descending on age and you have your upgrade backlog, ordered by urgency, without asking anyone.

Source IP. Where it runs. A cloud provider range for something you believe is on-premises is worth an hour of somebody’s time. Status is the fifth column worth watching: repeated failures from one source against a valid username is the pattern to alert on.

Reading the rhythm

A login row is an authentication, not an API call. That distinction is the most useful thing in the whole report.

A well-built client authenticates once and reuses the session or token until it expires, so it appears a handful of times a day. A badly built one authenticates on every call and produces thousands of rows. If one Application dominates your login count by an order of magnitude, you have found a client that re-authenticates per request.

Intervals are the other signal. Rows exactly every fifteen minutes, or every night at the same time, are a scheduled job. Irregular clusters during working hours are a person.

Finding the integration nobody documented

The sequence that works:

  1. Export ninety days and list distinct Application values. Anything you cannot name is the target.
  2. Note the user it logs in as and the source IP. The username often names the vendor, because whoever set it up called it something like svc_billing@company.com.
  3. Cross-reference in Setup under Connected Apps OAuth Usage. That page shows current app installs, the user count, and gives you the option to block or revoke.
  4. Check the API Type and version to work out what it touches, then check that user’s profile and permission sets to work out what it can reach.

Do not revoke first and wait for the complaint. That works, and it works during business hours on something that matters. Block it in a sandbox, or ask around for a week with the username and IP in hand, which is a far easier question to answer than “does anyone know about this integration”.

What Login History will not tell you

It records logins, not activity. A session that authenticated once and then ran a million queries is one row. For per-request visibility you need Event Monitoring, which is a separate, licensed product with its own log files.

It also will not show what the integration did. The login tells you who and how. Field history, the audit trail and the records themselves tell you what.

Frequently asked

Can I report on it? Yes. Login History is available as a report type, and a report grouped by Application with a rolling date filter is worth putting on an admin dashboard.

Does a refresh token exchange create a row? Yes, OAuth token activity appears here, which is why some apps show far more logins than you expect.

How do I keep history beyond six months? Export on a schedule, or use Event Monitoring’s login event log files.