DEV Community

Jan Ferko
Jan Ferko

Posted on

Building an All-in-One Automotive Data API - Looking for Developer Feedback

#api #webdev #discuss #sideprojects

Hey dev community! 👋
I've been working on CarAPI.dev - a comprehensive automotive data API platform. We're consolidating what typically requires 10+ different vendors into a single API. I'm at a point where I really need feedback from developers who work with vehicle data.

The Problem We're Solving

Last year, I was building an automotive marketplace and ended up juggling a ridiculous number of APIs:

  • VIN decoder for specs
  • License plate lookup service
  • Stolen vehicle database
  • European inspection records (MOT/TÜV)
  • Vehicle valuation service
  • Photo CDN provider
  • Payment calculator API
  • Mileage verification service
  • Multiple listing aggregators

Each had different auth methods, response formats, rate limits, and pricing models. I was spending more time managing integrations than building features.

What CarAPI.dev Offers

We've consolidated everything into a single API:
Vehicle Identification & Specs

  • VIN Decode - Full specifications, history, technical details
  • Plate to VIN - Convert any license plate to VIN

Verification & Safety

  • Stolen Vehicle Check - Real-time database lookups
  • Vehicle Inspection - European MOT, TÜV, TK/EK records
  • Mileage History - Odometer tracking for fraud detection

Market Data & Commerce

  • Vehicle Listings - Aggregated inventory with pricing
  • Vehicle Valuation - Market values and depreciation analysis
  • Vehicle Payments - Financing calculators and estimates
  • Vehicle Photos - High-quality image galleries

One API key, consistent JSON responses, single invoice.

Technical Decisions I Need Feedback On

1. Authentication - Query Parameter vs Headers

We use API key as a query parameter:

GET https://api.carapi.dev/v1/vin/decode?vin=1HGBH41JXMN109186&token=YOUR_API_KEY
Enter fullscreen mode Exit fullscreen mode 
GET https://api.carapi.dev/v1/plate/lookup?plate=ABC123&region=CA&token=YOUR_API_KEY
Enter fullscreen mode Exit fullscreen mode 
GET https://api.carapi.dev/v1/vehicle/stolen-check?vin=...&token=YOUR_API_KEY
Enter fullscreen mode Exit fullscreen mode

Controversial, I know. But my reasoning:

  • Works directly in browser for testing
  • No header configuration needed
  • Simpler for non-technical users
  • Easy to share examples

Is this a deal-breaker for you? Should we support header auth too?

2. The "Everything API" Approach

We're offering A LOT through one API. The alternative would be specialized APIs for each domain. Current structure:

/v1/vin/decode
/v1/plate/lookup
/v1/vehicle/stolen-check
/v1/vehicle/inspection
/v1/vehicle/mileage-history
/v1/listings/search
/v1/vehicle/valuation
/v1/vehicle/payments/calculate
/v1/vehicle/photos
Enter fullscreen mode Exit fullscreen mode

Is this too much in one API? Would you prefer:

  • Everything under one roof (current)
  • Separate APIs for different domains
  • GraphQL to query only what you need

3. Response Bundling vs Separation

When you decode a VIN, should we return EVERYTHING we have?
Option A - Kitchen sink approach:

GET /v1/vin/decode?vin=...&token=KEY

{
  "specs": {...},
  "stolen_status": {...},
  "inspection_history": [...],
  "mileage_records": [...],
  "valuation": {...},
  "photos": [...],
  "listings": [...]
}
Enter fullscreen mode Exit fullscreen mode

Option B - Selective with params:

GET /v1/vin/decode?vin=...&include=specs,stolen,valuation&token=KEY
Enter fullscreen mode Exit fullscreen mode

Option C - Separate endpoints for everything:

GET /v1/vin/decode?vin=...&token=KEY  // Just specs
GET /v1/vehicle/stolen-check?vin=...&token=KEY
GET /v1/vehicle/valuation?vin=...&token=KEY
Enter fullscreen mode Exit fullscreen mode

What's the right balance between convenience and payload size?

4. Regional Data Complexity

We handle multiple regions with different data:

  • US/Canada: VIN, state/province inspections
  • Europe: MOT (UK), TÜV (Germany), TK/EK (Netherlands), etc.
  • Different inspection standards per country

How should we handle this?

# Auto-detect
GET /v1/vehicle/inspection?vin=...&token=KEY
Enter fullscreen mode Exit fullscreen mode 
# Explicit country
GET /v1/vehicle/inspection?vin=...&country=DE&token=KEY
Enter fullscreen mode Exit fullscreen mode 
# Country-specific endpoints
GET /v1/de/vehicle/inspection?vin=...&token=KEY
Enter fullscreen mode Exit fullscreen mode

5. Documentation Approach

We have custom docs at https://docs.carapi.dev/ but wondering if we should add:

  • Swagger/OpenAPI - Industry standard, interactive
  • Postman Collection - Ready to run
  • GraphQL Playground - If we add GraphQL

The playground is behind login (for security). Is this friction worth it or should we have public test endpoints?

6. Pricing Across Diverse Features

Different features have vastly different costs for us:

  • VIN decode: Cheap (mostly static data)
  • Stolen check: Moderate (database queries)
  • Photos: Expensive (bandwidth)
  • Valuations: Very expensive (complex calculations)

Should we:

  • Single price for everything (simple but unfair?)
  • Feature-based pricing (complex but fair?)
  • Credit system (1 VIN decode = 1 credit, 1 valuation = 5 credits?)

Current thinking:

  • Free: 100 requests/month (any endpoint)
  • Indie: $29/mo for 5,000 requests
  • Startup: $99/mo for 25,000 requests

  • Scale: $299/mo for 100,000 requests

    7. Real-time vs Cached Data

    Different data has different freshness requirements:

  • VIN specs: Never change (cache forever)

  • Stolen status: Changes daily

  • Valuations: Monthly updates

  • Listings: Real-time

  • Mileage: When reported (sporadic)

How should we communicate this?

{
  "data": {...},
  "meta": {
    "cached": true,
    "cached_at": "2024-01-15T10:00:00Z",
    "data_freshness": "real-time|daily|weekly|static"
  }
}
Enter fullscreen mode Exit fullscreen mode

Or just use HTTP cache headers and trust developers to understand?

8. Bulk Operations for Fleet/Dealer Tools

Many users need bulk operations:

POST /v1/bulk/vin-decode?token=KEY
{
  "vins": ["VIN1", "VIN2", ...],
  "include": ["specs", "valuation", "stolen"]
}
Enter fullscreen mode Exit fullscreen mode

Questions:

  • Sync limit: 100 VINs reasonable?
  • Should bulk be cheaper per-request?
  • Async with webhooks or polling for large batches?

The Big Architecture Questions

1. Monolithic API vs Microservices

We're currently one big API. Should we split into:

identity.carapi.dev (VIN decode, plate lookup)
verification.carapi.dev (stolen, inspection, mileage)
market.carapi.dev (listings, valuation, payments)
media.carapi.dev (photos)
Enter fullscreen mode Exit fullscreen mode

Or is one API endpoint actually better DX?

2. API-First, No SDKs

We don't offer SDKs. Just REST. Is this refreshing or frustrating?
You write:

const response = await fetch(
  `https://api.carapi.dev/v1/vin/decode?vin=${vin}&token=${API_KEY}`
);
Enter fullscreen mode Exit fullscreen mode

Instead of:

const vehicle = await carapi.decode(vin);
Enter fullscreen mode Exit fullscreen mode

3. Payment Calculator Complexity

Should payment calculations be:

# Simple
GET /v1/vehicle/payments/calculate?price=50000&down=5000&term=60&apr=4.5&token=KEY
Enter fullscreen mode Exit fullscreen mode 
# Or complex with regional tax/fee support
POST /v1/vehicle/payments/calculate?token=KEY
{
  "vehicle_price": 50000,
  "down_payment": 5000,
  "trade_in": 10000,
  "location": {"state": "CA", "zip": "94105"},
  "financing": {
    "term_months": 60,
    "apr": 4.5
  },
  "include_taxes": true,
  "include_fees": true
}
Enter fullscreen mode Exit fullscreen mode

Specific Feature Questions

1. Vehicle Photos

  • Should we proxy/cache images or return direct CDN URLs?
  • Standardized sizes or original only?
  • Watermarking options?

2. Mileage History

  • How many historical points are useful?
  • Should we flag suspicious patterns automatically?

3. European Inspections

  • Is mixing MOT/TÜV/TK in one response confusing?
  • Should we standardize the format across countries?

4. Plate to VIN

  • Should this fail gracefully or error if no match?
  • Return multiple possible matches or best guess only?

What We Need From You

  1. What vehicle data are you currently struggling to get?
  2. Which of our features would you actually pay for?
  3. Is one unified API better or worse than specialized ones?
  4. What's missing that would make you switch from current providers?
  5. Is API key in URL params a deal-breaker?

Beta Access

Looking for ~50 developers who will actually integrate:

  • 6 months free access to ALL endpoints
  • Direct Slack channel with the team
  • Help shape the API design
  • Early access to new features

We need brutal honesty. "This endpoint is useless" or "This response format sucks" is exactly what we need to hear.

Why Another Vehicle API?

Beyond consolidation, we believe:

  • One vendor > ten vendors
  • Consistent data formats > different schemas per provider
  • Single invoice > expense report hell
  • Actual support > black holes

But maybe you prefer best-in-class point solutions?
The core question: Is an all-in-one vehicle data API solving a real problem, or are we trying to do too much?
Drop a comment or DM. Happy to discuss specific use cases, share example responses, or debate whether we're crazy for putting API keys in URLs.
Thanks for reading! 🚗

Top comments (0)