Canadian Vehicle Data: What APIs Actually Cover It?

If you're building automotive software for the Canadian market, you've probably discovered an uncomfortable truth: most vehicle APIs are built for the US market first, with Canadian coverage as an afterthought—if it exists at all.

The automotive data landscape is heavily US-centric. NHTSA provides free, comprehensive vehicle data for American vehicles. Transport Canada operates under completely different regulatory frameworks. Provincial variations add another layer of complexity. And if you're serving both markets, you need to handle cross-border data normalization that most APIs simply don't support.

This guide breaks down what's different about Canadian vehicle data, which APIs actually cover it, and how to build applications that work properly north of the border.

The Canadian Data Problem

The fundamental challenge with Canadian vehicle data isn't technical—it's regulatory. The US and Canada have separate automotive regulatory systems that don't share data infrastructure.

In the United States:

• NHTSA (National Highway Traffic Safety Administration) maintains the VPIC database
• Every vehicle sold requires a 565 submittal with complete specifications
• All data is public, free, and accessible via API
• Recalls, complaints, and safety data are published daily

In Canada:

• Transport Canada handles vehicle safety regulation
• CMVSS (Canadian Motor Vehicle Safety Standards) declarations are required
• Most data isn't systematically digitized or publicly accessible
• We filed an ATI request and learned Transport Canada has 32,000+ consumer complaints—but says it would take "years" to release them

This regulatory asymmetry creates real problems for developers. An API that works perfectly for US vehicles might return incomplete data—or nothing at all—for Canadian-market vehicles.

What's Actually Different in Canada?

VIN Structure: Same Format, Different Data

Canadian VINs follow the same ISO 3779 17-character format as US VINs. The structure is identical:

• Positions 1-3: World Manufacturer Identifier (WMI)
• Positions 4-8: Vehicle Descriptor Section (VDS)
• Position 9: Check digit
• Position 10: Model year
• Position 11: Assembly plant
• Positions 12-17: Production sequence

But here's where it gets complicated:

Some vehicles are built specifically for the Canadian market with unique VIN patterns. The Honda Civic built in Alliston, Ontario may have different equipment packages than US-spec Civics. Some manufacturers use different WMI codes for Canadian production facilities.

The good news: because most manufacturers also sell in the US, they submit 565 data to NHTSA that covers Canadian-market vehicles. VIN decoding accuracy for Canadian vehicles is typically 95%+ using NHTSA data—but that remaining 5% includes Canadian-exclusive trims and equipment packages.

For implementation details on VIN decoding, see our JavaScript VIN decoder guide or the technical deep dive on building VIN decoders.

Recalls: Two Separate Systems

This is where US-focused APIs completely fall apart for Canadian applications.

NHTSA Recalls (US):

• Recall ID format: 24V-123
• Published daily, freely accessible
• Searchable by VIN
• Complete historical database

Transport Canada Recalls (Canada):

• Recall ID format: 2024-123 (year-sequence)
• Different notification process
• Separate affected vehicle populations
• French/English bilingual requirements

A vehicle might be recalled in both countries for the same defect—but with different recall numbers, different timelines, and potentially different repair procedures. Your application needs to query both systems and present unified results.

Here's a real example: The 2023 Honda CR-V has had 8 Transport Canada recalls since 2020, affecting over 700,000 units for issues ranging from fuel pump failures to steering problems. If you're only checking NHTSA data, you're missing critical safety information for Canadian owners.

Market Data: Provincial Variations

Canadian automotive markets vary significantly by province. A 2024 Toyota RAV4 might be priced $3,000 higher in British Columbia than in Alberta due to different provincial taxes, fees, and market dynamics.

Quebec adds another layer: language requirements mean that any consumer-facing application must support French, and vehicle documentation has distinct formatting requirements.

For developers building marketplace or valuation tools, you need:

• Provincial pricing data (not just national averages)
• Tax and fee calculations by province
• Currency handling (CAD, not USD)
• Odometer in kilometres (not miles)
• French language support for Quebec

API Coverage Comparison

Let's be direct about what works and what doesn't for Canadian vehicle data:

NHTSA vPIC: Free and comprehensive for VIN decoding, but only covers vehicles with US 565 submittals. No Canadian recalls, no market data. See our free VIN decoder API comparison for detailed analysis.

Marketcheck: Good US coverage, some Canadian listings, but no Transport Canada recall integration. Odometer handling varies by data source.

Auto.dev: US-focused. Canadian coverage is minimal.

Cardog: Built with Canadian market as a first-class concern. Native Transport Canada recall support, provincial listings data, and proper metric/CAD handling. Currently tracking over 340,000 unique vehicles across 2,200+ Canadian dealerships. Official SDKs for TypeScript (npm install @cardog/api) and Python (pip install cardog).

Working with Canadian Data

VIN Decoding

For Canadian VINs, the decoding process is identical to US VINs—but you should be aware of coverage gaps:

import { decodeVIN } from '@cardog/corgi';

const result = await decodeVIN('2T3DWRFV3LW094009');
// Returns: 2020 Toyota RAV4 Hybrid Limited

// Works for most Canadian vehicles because Toyota
// submits 565 data to NHTSA for all North American models

The Corgi VIN decoder handles Canadian VINs the same as US VINs because it's built on NHTSA's VPIC database, which includes most vehicles sold in Canada.

Canadian Recalls

Querying Transport Canada recalls requires a separate data source. Here's how the Cardog SDKs handle it:

TypeScript (npm install @cardog/api):

import { CardogClient } from "@cardog/api";

const client = new CardogClient({ apiKey: "your_api_key" });

// Search Transport Canada recalls
const recalls = await client.recalls.search({
  country: "ca",
  makes: ["Honda"],
  models: ["CR-V"],
  year: { min: 2020, max: 2024 },
});

// Returns Transport Canada recall data:
// - Recall number: "2024-606"
// - Units affected: 61,175
// - Issue: High-pressure fuel pump defect
// - Corrective action: Inspect and replace if necessary

Python (pip install cardog):

from cardog import Cardog

client = Cardog(api_key="your_api_key")

# Search Transport Canada recalls
recalls = client.recalls.search(
    "ca",
    makes=["Honda"],
    models=["CR-V"],
    year_min=2020,
    year_max=2024,
)

for recall in recalls.recalls:
    print(f"{recall.year} {recall.make}: {recall.title}")

The API returns Transport Canada's official data including bilingual French/English descriptions, affected unit counts, and manufacturer recall numbers.

Canadian Listings

When searching Canadian inventory, proper handling means:

TypeScript:

const listings = await client.listings.search({
  makes: ["Toyota"],
  models: { Toyota: ["RAV4"] },
  year: { min: 2020, max: 2024 },
  limit: 20,
});

// Results include:
// - Prices in CAD
// - Odometer in kilometres
// - Provincial location data
// - Dealer information with Canadian addresses

Python:

results = client.listings.search(
    makes=["Toyota"],
    models=["RAV4"],
    year_min=2020,
    year_max=2024,
    limit=20,
)

for listing in results.listings:
    print(f"{listing.year} {listing.make} {listing.model} - ${listing.price}")

Cross-Border Considerations

If you're building applications that serve both US and Canadian users, you need to handle several data normalization challenges:

Odometer Conversion

Canadian odometers are in kilometres. US odometers are in miles. This seems trivial until you're comparing vehicles across borders or building valuation models.

Cardog stores all odometer values in kilometres internally—a 50,000 km vehicle is stored as 50000, not converted to miles. This prevents the precision loss that comes from repeated conversions and provides a single source of truth.

When displaying to US users, convert at the presentation layer: km * 0.621371 = miles.

Currency Handling

Don't convert CAD to USD in your database. Store the original currency with each record. Exchange rates fluctuate, and historical pricing analysis becomes meaningless if you've converted everything to a single currency at varying rates.

Provincial Data

Each Canadian province has different:

• Sales tax rates (PST, GST, HST combinations)
• Registration fees
• Inspection requirements
• Lemon law protections (see our Canadian lemon law guide)

Your application should store province codes and apply the appropriate rules at runtime rather than baking assumptions into the data.

Building for Both Markets

The practical approach for cross-border applications:

1. Use a Canada-aware API for core data. Don't rely solely on US-centric services.

2. Store data in metric/CAD. Convert at the presentation layer for US users.

3. Query both recall systems. A vehicle might have recalls in one country but not the other.

4. Handle provincial variations. Canada isn't monolithic—BC, Ontario, and Quebec have meaningful differences.

5. Support French. If you're serving Quebec, it's not optional.

Cardog was built by Canadians who were frustrated by the US-centric bias in automotive APIs. Every endpoint supports Canadian data natively. Transport Canada recalls are updated daily. Listings data covers all provinces with proper CAD/km handling.

If you're building for the Canadian market, start with our VIN decoder guide for the basics, check our API documentation for implementation details, or explore Canadian vehicles by province to see the data in action.