FMCSA Carrier Safety API — DOT Lookup, BASIC Scores, Insurance avatar

FMCSA Carrier Safety API — DOT Lookup, BASIC Scores, Insurance

Pricing

from $8.00 / 1,000 carrier records

Go to Apify Store
FMCSA Carrier Safety API — DOT Lookup, BASIC Scores, Insurance

FMCSA Carrier Safety API — DOT Lookup, BASIC Scores, Insurance

Look up any motor carrier's DOT/MC safety profile — BASIC scores, authority, insurance, and OOS status — via FMCSA's official QCMobile API. No scraping.

Pricing

from $8.00 / 1,000 carrier records

Rating

0.0

(0)

Developer

Moose & Raven

Moose & Raven

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

0

Monthly active users

39 minutes ago

Last modified

Share

Look up any motor carrier's DOT/MC safety profile via FMCSA's official QCMobile API — no scraping. Query by USDOT number, legal/DBA name, or MC docket number to get a normalized registration snapshot, BASIC safety percentiles, operating authority, insurance on-file/required status, and out-of-service status, with optional change-monitoring for scheduled runs (flags OOS orders, authority/safety-rating changes, insurance lapses, and BASIC percentile shifts since the last run).

Live-validated against the real API with a real webKey — every field name and nesting shape in this README and OUTPUT_SCHEMA.md is confirmed against real responses, not assumed from FMCSA's own docs (which turned out to be missing several fields, including all insurance fields, and had one field name wrong).

What makes this different

This actor calls only the official QCMobile REST API (mobile.fmcsa.dot.gov/qc/services), which FMCSA built and documents explicitly "to encourage development of products, tools or services." It does not scrape SAFER, the live SMS carrier profile pages, or li-public.fmcsa.dot.gov. That distinction matters here specifically because the SMS website (ai.fmcsa.dot.gov/SMS) runs CAPTCHA + Cloudflare anti-bot protection — confirmed during an access screen before this actor was built — so it is treated as a target that actively resists automation and is out of scope.

Every other DOT/carrier actor we surveyed bundles at most a plain registration snapshot. This one adds BASIC percentiles, authority status, out-of-service orders, insurance on-file/required flags, and safety rating in the same normalized record, plus optional run-over-run change flagging for scheduled monitoring, not just one-shot lookups. The insurance-lapse capability in particular is a real signal not commonly offered through an official, non-scraping channel.

How it works

  • Try it with no key at all: leave dotNumbers/carrierNames/docketNumbers empty and enableNewAuthorityFeed on (the default) to see newly-registered motor carriers from FMCSA's official Company Census File — a separate, keyless public API. No signup needed for this part.
  • Bring your own FMCSA QCMobile webKey (fmcsaWebKey input) to look up specific carriers by dotNumbers, carrierNames, and/or docketNumbers — names and docket numbers are resolved to USDOT numbers first (one carrier can match multiple names). Register a free developer account via Login.gov at mobile.fmcsa.dot.gov — no cost, not affiliated with Apify. Each run uses your key only; usage is never pooled across customers. Only required when you actually request a carrier lookup — not needed for the new-authority feed alone.
  • For each resolved carrier, fetches the registration snapshot (which itself includes insurance on-file/required flags, safety rating, authority status, and crash/inspection stats — all in one call) and, optionally, BASIC percentiles, a fuller authority record, cargo authority, operation classification, and out-of-service orders.
  • Insurance-lapse detection: the base snapshot includes bipd/bond/cargo insurance OnFile (a dollar-amount-like value) and Required ("Y"/"N"/"u") flags. A carrier with insurance required but nothing on file is a live, real, and — during testing — actually observed condition (a real carrier's bipdInsuranceRequired: "Y" with
    bipdInsuranceOnFile: "0"
    ). monitorMode flags transitions into/out of this state.
  • Optional change-monitoring (monitorMode): compares this run's snapshot for each carrier against the last run's (Apify key-value store) and emits a separate change-flag record for anything that shifted — allowed-to-operate status, out-of-service order count, safety rating, an insurance-lapse transition, or a watched BASIC percentile. Designed for scheduled runs watching a fixed carrier list (e.g. a broker's active lane partners, a factoring company's client roster). Confirmed live: a second run against unchanged data produces zero false-positive change flags.
  • A quota guard (maxRecordsPerRun) caps carriers processed per run.
  • Fails the whole run immediately on an invalid webKey, rather than quietly retrying the same bad key against every carrier and reporting a misleadingly "successful" zero-record run.
  • Optional new-authority feed (enableNewAuthorityFeed): surfaces newly-registered motor carriers from FMCSA's official Company Census File (a separate, keyless, public Socrata API at data.transportation.gov) — no fmcsaWebKey usage or QCMobile quota consumed for this part. Supports the same monitorMode incremental-checkpoint pattern as carrier snapshots.

Why this matters for broker/shipper carrier selection

A federal court has held that freight brokers must exercise reasonable care in selecting carriers, including checking FMCSA safety data. Schramm v. Foster, 341 F. Supp. 2d 536, 551-53 (D. Md. 2004). That ruling was made at the summary-judgment stage, predicting how Maryland law would apply to one broker's carrier-selection decision — it is not a federal regulation, and broker negligent-selection liability is an active, unsettled area of law (a related preemption question is currently pending before the courts). This actor doesn't make that legal question go away; it simply makes the underlying FMCSA safety data (BASIC percentiles, authority status, out-of-service orders, insurance-lapse flags) easy to check and re-check on a schedule, which is the kind of documentation a broker or shipper doing carrier-selection due diligence would want on file.

Limitations (read before you rely on this)

  • Insurance-lapse detection is flag-level, not full policy detail. You get on-file/required booleans and a dollar-amount-like figure per insurance type, not the insurer name, policy number, or effective date a human would see on li-public.fmcsa.dot.gov. That fuller detail remains out of scope — li-public.fmcsa.dot.gov is a live query portal with no documented API or stated automation invitation, and this actor avoids scraping government portals wherever a sanctioned alternative exists. The flag-level data is genuinely useful on its own (it's exactly what's needed to answer "does this carrier still have insurance on file") and comes from the same sanctioned QCMobile call as everything else.
  • Only 5 of 7 BASIC categories are available. Hazmat and Crash Indicator BASICs are not publicly disclosed by FMCSA at all (confirmed via their own SMS documentation) — no actor, ours included, can legitimately offer them without non-public access.
  • Name search can return multiple carriers per name (fuzzy match) and is capped at the API's first-50-results behavior; for precise vetting, prefer dotNumbers.
  • oosDate on the base snapshot is historical, not necessarily current — it's the date the carrier was last placed out of service, which could be old news. The oos array (fetched separately, on by default) is the authoritative "does this carrier have an order on file right now" signal.

Pricing model (proposed, not yet live)

Pay-per-event, to be finalized at publish time:

  • carrier-record — per carrier snapshot returned (bundles registration + insurance flags + safety rating + BASICs + authority + OOS orders)
  • new-authority-record — per newly-registered carrier returned by the new-authority feed
  • monitor-run — one charge per scheduled monitor-mode run, in addition to per-carrier charges

Input

Key fields (see the Input tab for the full form): fmcsaWebKey (bring your own — only needed for carrier lookups, not for the new-authority feed), dotNumbers, carrierNames, docketNumbers, includeBasics, includeAuthority, includeCargoCarried, includeOperationClassification, includeOos, monitorMode, maxRecordsPerRun, enableNewAuthorityFeed (on by default), newAuthorityLookbackDays, newAuthorityStateFilter, censusAppToken.

Output

Each dataset item has a recordType of "carrier-safety-snapshot", "carrier-change-flag", "new-authority", "new-authority-status" (only when the new-authority feed was truncated or skipped), or "monitor-config-warning" (only when a carrier's monitor-mode config changed between runs). See the Output tab for the full field reference.

Local development

npm install
npm test # recorded-fixture unit tests, no webKey needed
npx apify-cli run # local end-to-end run — requires a real fmcsaWebKey in
# storage/key_value_stores/default/INPUT.json

Support

Built and maintained by Moose & Raven. Questions or issues: support@mooseandraven.com.