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

Jan Ferko — Mon, 29 Sep 2025 13:07:05 +0000

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

GET https://api.carapi.dev/v1/plate/lookup?plate=ABC123&region=CA&token=YOUR_API_KEY

GET https://api.carapi.dev/v1/vehicle/stolen-check?vin=...&token=YOUR_API_KEY

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

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": [...]
}

Option B - Selective with params:

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

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

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

# Explicit country
GET /v1/vehicle/inspection?vin=...&country=DE&token=KEY

# Country-specific endpoints
GET /v1/de/vehicle/inspection?vin=...&token=KEY

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"
  }
}

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"]
}

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)

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}`
);

Instead of:

const vehicle = await carapi.decode(vin);

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

# 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
}

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

What vehicle data are you currently struggling to get?
Which of our features would you actually pay for?
Is one unified API better or worse than specialized ones?
What's missing that would make you switch from current providers?
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! 🚗

DEV Community: Jan Ferko