FMCSA API for freight brokers: SAFER, QCMobile, and what each endpoint actually returns.

The FMCSA provides two programmatic APIs for carrier data: the SAFER web service (carrier registration and authority) and QCMobile (safety performance and inspection records). Together they are the authoritative public data source for US carrier verification — and they are free. This guide covers both: what each endpoint returns, how to authenticate, rate limits, common usage patterns for broker software, and how Keelway integrates them into the carrier trust scoring pipeline. Both operators who want to understand what a tool like Keelway is actually checking and developers building carrier verification into their own software will find this useful.

The FMCSA data universe for carrier verification

When a broker wants to verify a carrier, they are asking three distinct questions: Is this carrier registered and authorized to operate? Are they insured? Do they have a clean safety record? FMCSA data answers all three, but from different systems:

• SAFER web service — registration, authority status, insurance certificates, entity information. The fastest and most commonly used for authority checks.
• QCMobile API — safety performance data, BASIC scores, inspection records, crash data. Slower to query and more data-heavy.
• L&I (Licensing and Insurance) database — accessible via SAFER, this is where insurance certificates are stored. Querying this confirms whether a carrier has active cargo and liability coverage.

FMCSA SAFER API: the basics

The SAFER web service is available at https://mobile.fmcsa.dot.gov/qc/services/ and at the older SOAP endpoint at https://webservices.fmcsa.dot.gov/services/. FMCSA has been gradually migrating to the newer REST-based QCMobile interface, but the SAFER service remains operational and is the primary source for registration and authority data.

Registration: request an API key at ai.fmcsa.dot.gov. The registration process is straightforward — provide your name, organization, and intended use. Keys are typically issued within one business day.

Core SAFER endpoints

The three most commonly used SAFER endpoints for broker software:

Carrier by MC number:

GET https://mobile.fmcsa.dot.gov/qc/services/carriers/
    docket-number/{mc_number}?webKey={your_api_key}

# Example
curl "https://mobile.fmcsa.dot.gov/qc/services/carriers/
     docket-number/847321?webKey=YOUR_KEY"

Carrier by USDOT number:

GET https://mobile.fmcsa.dot.gov/qc/services/carriers/
    {dot_number}?webKey={your_api_key}

Carrier search by name:

GET https://mobile.fmcsa.dot.gov/qc/services/carriers/
    name/{company_name}?webKey={your_api_key}&start=1&size=10

Sample SAFER response

A carrier lookup by MC number returns a JSON object with this structure (simplified for readability):

{
  "content": {
    "carrier": {
      "dotNumber": "2847291",
      "legalName": "Ortega Brothers Transport Inc.",
      "dbaName": null,
      "carrierOperation": {
        "carrierOperationCode": "A",
        "carrierOperationDesc": "Interstate"
      },
      "hmFlag": "N",
      "pcFlag": "N",
      "statusCode": "A",
      "censusTypeId": {
        "id": "C",
        "description": "Carrier"
      },
      "entityType": {
        "id": "C",
        "description": "CARRIER"
      },
      "phyStreet": "4821 Laredo Industrial Blvd",
      "phyCity": "Laredo",
      "phyState": "TX",
      "phyZipcode": "78040",
      "phyCountry": "US",
      "usdotStatus": "ACTIVE",
      "allowedToOperate": "Y",
      "bipdInsuranceRequired": "Y",
      "bipdInsuranceOnFile": "Y",
      "bipdRequiredAmount": "750000",
      "cargoInsuranceRequired": "N",
      "cargoInsuranceOnFile": "Y",
      "bondInsuranceRequired": "N",
      "bondInsuranceOnFile": "N",
      "totalDrivers": 4,
      "totalPowerUnits": 3
    }
  }
}

Key fields to check for broker vetting purposes: allowedToOperate (should be "Y"), usdotStatus (should be "ACTIVE"), bipdInsuranceOnFile (should be "Y"), and legalName (compare against the email sender's claimed company name).

The authority status field in detail

The allowedToOperate field is the most important single boolean for broker software — it reflects whether the carrier currently has active operating authority for the relevant cargo type. However, it is not the only status field that matters. The full authority picture requires checking:

• usdotStatus — ACTIVE, INACTIVE, or OUT-OF-SERVICE. An inactive USDOT is a hard stop.
• Authority types — a carrier may have active common authority but not contract authority for the specific type of freight you are tendering. The authority type detail is available in the carrier rights object.
• Insurance on file — bipdInsuranceOnFile confirms the carrier has bodily injury and property damage coverage on file with FMCSA. This is the minimum; for cargo coverage, check cargoInsuranceOnFile as well.
• totalPowerUnits — this is a useful proxy for carrier size. A carrier claiming a large fleet but showing 1–2 power units in FMCSA data warrants manual review.

QCMobile API: safety performance data

The QCMobile API provides safety performance data including BASIC (Behavior Analysis and Safety Improvement Categories) scores, inspection records, and crash data. It is a separate API from SAFER with a different endpoint structure.

Base URL: https://mobile.fmcsa.dot.gov/qc/services/

Carrier basics (same endpoint as SAFER):

GET https://mobile.fmcsa.dot.gov/qc/services/carriers/
    {dot_number}?webKey={your_api_key}

Carrier BASIC scores:

GET https://mobile.fmcsa.dot.gov/qc/services/carriers/
    {dot_number}/basics?webKey={your_api_key}

The BASIC response includes scores across the seven SMS categories: Unsafe Driving, Hours-of-Service Compliance, Driver Fitness, Controlled Substances/Alcohol, Vehicle Maintenance, Hazardous Materials Compliance, and Crash Indicator. Scores above the alert threshold in any category indicate elevated safety risk.

Sample BASIC response (abbreviated):

{
  "content": {
    "basics": [
      {
        "basicId": 1,
        "basicDescription": "Unsafe Driving",
        "percentile": 45,
        "onRoadPerformance": "Satisfactory",
        "inspectionsWithViolation": 0,
        "totalInspections": 8,
        "outOfServiceRate": 0.0,
        "measureValue": 23.4,
        "alertIndicator": "N"
      },
      {
        "basicId": 2,
        "basicDescription": "HOS Compliance",
        "percentile": 62,
        "onRoadPerformance": "Satisfactory",
        "inspectionsWithViolation": 1,
        "totalInspections": 8,
        "outOfServiceRate": 0.0,
        "measureValue": 31.2,
        "alertIndicator": "N"
      }
    ]
  }
}

The L&I (Licensing and Insurance) database

Insurance certificate details — carrier names, policy numbers, coverage amounts, effective dates — are accessible through the SAFER service via the carrier detail response. The most useful endpoint for insurance verification:

GET https://mobile.fmcsa.dot.gov/qc/services/carriers/
    {dot_number}/insurance?webKey={your_api_key}

The response includes a list of insurance filings with fields for insurer name, policy number, coverage amount, effective date, and cancellation date. For broker due-diligence, you want to confirm: the policy is active (no cancellation date in the past), the coverage amount meets your minimum threshold (typically $750,000 for BIPD), and cargo coverage is present if your load type requires it.

Rate limits and caching strategy

FMCSA does not publish hard rate limits, but the practical limit observed by developers is approximately 1,000–2,500 requests per day before throttling becomes visible. For applications that need to verify hundreds of carriers per day, this ceiling is reachable quickly.

The standard production architecture for broker software:

• Cache verified carriers locally with a 24–72 hour TTL for authority and insurance data. Authority status does not change minute-to-minute; a cached result from this morning is valid for most booking decisions.
• Batch-verify known carriers overnight — if your brokerage maintains a preferred carrier list, run batch verification nightly and store results in your own database. Real-time lookups then only happen for carriers not in your cache.
• Force a fresh lookup for: any carrier not seen in the last 7 days; any carrier whose authority status was non-active in the last lookup; and any carrier flagged with other risk signals (domain mismatch, new MC number).
• Rate limit your application layer — implement a queue for FMCSA API calls with a configurable request rate (e.g., 10 requests per second maximum) to avoid hitting upstream throttles during peak inbox processing.

Common usage patterns for broker software

Pattern 1: New carrier onboarding

When a carrier appears in your system for the first time (first email reply to a posted load, first direct contact), trigger a full SAFER + QCMobile lookup: authority status, insurance on file, BASIC scores, and power unit count. Store results with a timestamp. This becomes your baseline carrier record.

Pattern 2: Real-time triage enrichment

When an inbound carrier email arrives with an MC number in the signature, trigger a cache-or-fetch lookup: return cached data if fresh, otherwise queue a live FMCSA call. The goal is to have trust score data available before the broker opens the email — typically within 30–60 seconds of receipt for a new carrier.

Pattern 3: Pre-booking final check

Before generating a rate confirmation, run a fresh authority check (not cached) to confirm the carrier is still active. This protects against the edge case of a carrier whose authority was revoked in the window between your cached verification and the booking moment. This check should be synchronous (blocking the confirmation generation) and fast — the API response time for a single SAFER lookup is typically under 500ms.

Pattern 4: Periodic compliance monitoring

For preferred carriers, run a weekly FMCSA refresh on all carriers in your active list. Flag any whose authority status has changed, insurance has lapsed, or BASIC scores have crossed alert thresholds. This is the monitoring pattern that catches authority revocations before they affect an in-transit load.

What FMCSA data does not tell you

The FMCSA APIs provide authoritative registration and safety data, but there are several fraud signals they do not address:

• Identity theft. A stolen MC number passes all FMCSA checks because the underlying MC is legitimate. The check does not verify that the person emailing you is actually affiliated with the company on the MC.
• Domain spoofing. FMCSA does not have email domain data. A carrier emailing from a domain that does not match their registered company name is invisible to FMCSA lookups alone.
• Double-brokering history. There is no FMCSA record of a carrier's double-brokering incidents. This signal requires cross-referencing against commercial databases (Highway, MyCarrierPortal, Carrier411) or your own incident history.

This is why FMCSA checks are a necessary but not sufficient component of a complete trust score. For the full architecture of how Keelway combines FMCSA data with domain verification and fraud signals, see the carrier trust score methodology.

How Keelway uses the FMCSA API

Keelway queries FMCSA SAFER and QCMobile for every MC number that appears in an inbound carrier email reply. The integration runs asynchronously: when a reply arrives, the MC number is extracted from the email body or signature, a cache lookup happens first, and if the cache is stale or the carrier is new, a live FMCSA call is queued.

The FMCSA data feeds into the trust score as one of several components. The weight given to authority status, insurance on file, and BASIC scores depends on the cargo type and the broker's configured risk settings. A carrier with a clean FMCSA record but a 4-day-old email domain gets flagged despite passing FMCSA checks. A carrier with a slightly elevated BASIC score but a 5-year domain and consistent lane history with the brokerage is treated differently than a carrier with the same BASIC score and no history.

The trust score is always surfaced with the specific signals that drove it — not a number alone but a set of reasons the broker can evaluate. For more on how the score is structured, see the carrier trust score page. For the full context of how carrier verification fits into the SMB broker workflow, see the SMB broker stack guide for 2026.

Additional FMCSA resources for developers

The official FMCSA API documentation is at the QCMobile developer guide and the FMCSA AI portal downloads page, which includes the full field-level data dictionary. For the SOAP-based SAFER service, the WSDL is available at https://webservices.fmcsa.dot.gov/services/USWebServices.asmx?WSDL. The REST interface is preferred for new development.

For questions about carrier fraud signals that go beyond FMCSA data, see our guide to spotting double brokering from carrier emails.