VIN Manufacturer API - Vehicle API Blog

You need to reliably identify the manufacturer behind any 17-character VIN so your app can show compliant disclosures, route service workflows, or gate features by OEM. By the end of this guide, you will be able to call Vehicle API’s VIN decode endpoint, read the manufacturer field, handle nulls and errors, cache results, and understand coverage and quotas for production use.

What the manufacturer field gives you

The VIN “manufacturer” field is the OEM entity responsible for the vehicle’s production as published by NHTSA’s vPIC. It’s distinct from “make” (consumer-facing brand) and complements plant-level details such as country, state, and city. For dealer tools, marketplaces, fleet and insurance apps, and AI agents, this field enables:

OEM-specific policy and warranty routing (e.g., associating vehicles to manufacturer programs).
Regulatory or compliance labeling where the legal manufacturer entity is required.
Data normalization when multiple brands share platforms but have a single corporate manufacturer record.

Vehicle API exposes this as part of the VIN decode response, with worldwide decoding and fullest attribute coverage for US-market vehicles. Non-published fields return null.

Endpoint and authentication

Use the VIN decode endpoint to retrieve the manufacturer and other decoded details:

Base URL: https://vehicles-api.com/api/v1
Endpoint: POST /vin/decode
Authentication: X-API-Key: YOUR_API_KEY header (Authorization: Bearer YOUR_API_KEY also works)
Request body: JSON with a single vin property

Every response is wrapped in a predictable envelope with top-level status, source, and data. On error, the envelope includes status set to error with error.code and error.message.

Explore the whole platform and plans at vehicles-api.com, and start building with the Documentation.

Official cURL request

Copy, paste, and run this request. It decodes the control VIN (a 2003 Honda Accord). Replace YOUR_API_KEY with your key when you’re ready.

curl -X POST "https://vehicles-api.com/api/v1/vin/decode" -H "X-API-Key: YOUR_API_KEY" -H "Content-Type: application/json" -d '{"vin":"1HGCM82633A004352"}'

Official JSON response

The API responds with an envelope and a data object containing the manufacturer field along with related attributes:

{
"status": "success",
"source": "nhtsa",
"data": {
"vin": "1HGCM82633A004352",
"valid": true,
"year": 2003,
"make": "HONDA",
"model": "Accord",
"trim": "EX-V6",
"body": "Coupe",
"doors": 2,
"vehicle_type": "PASSENGER CAR",
"engine": {
"cylinders": 6,
"displacement_l": 3,
"configuration": "V-Shaped",
"model": "J30A4",
"hp": 240,
"fuel": "Gasoline"
},
"fuel_type": "Gasoline",
"electrification_level": null,
"ev_drive_unit": null,
"battery_kwh": null,
"charger_level": null,
"charger_power_kw": null,
"drive": null,
"transmission": {
"style": "Automatic",
"speeds": 5
},
"plant": {
"country": "UNITED STATES (USA)",
"city": "MARYSVILLE",
"state": "OHIO"
},
"manufacturer": "AMERICAN HONDA MOTOR CO., INC."
}
}

Fields you’ll use for manufacturer workflows

Focus on these keys for manufacturer-driven logic:

status: "success" on success. On error, see error.code and error.message.
source: "nhtsa" (the authoritative decode source in this response).
data.vin: The 17-character VIN echoed back.
data.valid: Boolean indicating VIN checksum/format validity as decoded.
data.manufacturer: The OEM legal entity name (e.g., "AMERICAN HONDA MOTOR CO., INC.").
data.make, data.model, data.year: Consumer-facing brand, model, and model year (useful for display or matching US safety data).
data.plant.country/state/city: Assembly location, often paired with manufacturer for sourcing logic.
Nullables: drive, electrification_level, ev_drive_unit, battery_kwh, charger_level, charger_power_kw may be null when NHTSA does not publish those fields for the VIN.

Units and formats:

engine.displacement_l is in liters, hp is horsepower, transmission.speeds is an integer count.
Strings like manufacturer, make, model, body, vehicle_type are uppercase/title case based on the source and should be normalized in your app as needed.

Python example: decode VIN and read manufacturer

This sample calls the same endpoint and extracts the manufacturer with a few related fields for display and routing:

import requests

API_URL = "https://vehicles-api.com/api/v1/vin/decode"
API_KEY = "YOUR_API_KEY"
VIN = "1HGCM82633A004352"

headers = {
"X-API-Key": API_KEY,
"Content-Type": "application/json",
}

payload = {"vin": VIN}

resp = requests.post(API_URL, json=payload, headers=headers, timeout=10)
resp.raise_for_status()
envelope = resp.json()

if envelope.get("status") != "success":
err = envelope.get("error", {})
raise RuntimeError(f"Vehicle API error: {err.get('code')} - {err.get('message')}")

data = envelope.get("data", {}) or {}

manufacturer = data.get("manufacturer")
make = data.get("make")
model = data.get("model")
year = data.get("year")
plant = data.get("plant") or {}
plant_city = plant.get("city")
plant_state = plant.get("state")
plant_country = plant.get("country")

print(f"VIN: {data.get('vin')}")
print(f"Valid: {data.get('valid')}")
print(f"Manufacturer: {manufacturer}")
print(f"Display: {year} {make} {model}")
print(f"Plant: {plant_city}, {plant_state}, {plant_country}")

Response envelope and error handling

All responses follow this pattern:

On success: status is "success", source identifies the upstream dataset (here, "nhtsa"), and data contains the decoded vehicle object.
On error: status is "error" and the body includes error.code and error.message. Handle both transport-level errors (HTTP 4xx/5xx) and application-level errors (status = error).

Null handling is essential: if NHTSA does not publish a field, Vehicle API returns null for that key. Your integration should not assume optional fields like drive or EV-related keys are present for ICE vehicles.

Coverage and data sources

VIN decoding: Works worldwide for any 17-character VIN, with fullest detail for US-market vehicles.
US safety datasets: Recalls, owner complaints, and NCAP crash ratings are US-market only and matched by make, model, and year. They are not returned by the decode endpoint shown here; fetch them via the relevant endpoints if/when you integrate safety features.
Dutch plates: Supported via RDW open data and do not include a VIN. Use plate-based lookups when you need Dutch registration attributes; do not attempt to backfill a VIN from an RDW plate.
Not a vehicle history report: No title, accident, or ownership history is included.

Learn more about platform capabilities at vehicles-api.com and test tool-based integrations via the MCP server endpoint.

Practical integration notes for the manufacturer field

Normalization and display

The manufacturer value is a legal entity string (e.g., “AMERICAN HONDA MOTOR CO., INC.”). If you need a cleaner display label, map or transform it to a canonical OEM display list in your app while keeping the raw value for audit or compliance.
Use make/model/year for user-facing labels. Keep manufacturer for routing, compliance, and deduplication across related brands or corporate entities.

Matching and joins

Join manufacturer with plant metadata to power sourcing filters (e.g., “Show vehicles manufactured by X in the USA”).
When pulling US safety datasets, match by make, model, and year, not the VIN itself.

Nulls and fallbacks

When manufacturer is present, prefer it to make for OEM-level logic. If it is null (rare on US-market decodes), fall back to make and WMI-derived logic in your app.
If plant fields are null, do not attempt to infer plant location from manufacturer; treat them as independent signals.

Caching decoded VINs

VIN decode responses are static for a given VIN in the scope of manufacturer, make, model, year, and plant. To reduce latency and cost:

Cache successful decodes keyed by VIN. A long TTL (e.g., weeks or months) is appropriate for manufacturer and other decode fields.
Cache nulls too. If a field is not provided by NHTSA for a VIN, repeated calls will return null.
Handle revalidation by background refresh if you want to capture any late upstream corrections; your foreground UX should serve cached values immediately.

Rate limits, monthly quota, and throughput

Vehicle API enforces per-plan rate limits and monthly quotas. Exact numbers vary by plan. Monitor usage in your account and consult the Documentation for current policies.

Implement exponential backoff or token-bucket client-side rate limiting to avoid spikes.
Prefer caching to reduce repeat decodes for the same VINs across your fleet or marketplace inventory.
Surface “degraded” states in your application when you near quota and rely on cache hits.

Production concerns: timeouts, retries, and idempotency

Timeouts: Use conservative request timeouts (e.g., 5–10 seconds) and fail fast to cached values when available.
Retries: Retries should be limited to idempotent decode requests and only for network/transient server errors, with jittered backoff.
Idempotency: The decode request body is deterministic per VIN, making client-side retries safe.

MCP server for AI agents and tools

If you are building AI agents that need structured access to the same VIN decode capabilities, Vehicle API is also exposed as an MCP server at MCP. You can centralize manufacturer retrieval in your agent tooling and reuse the same authentication and response semantics. Choose the REST endpoint for conventional services and the MCP server for tool-calling agents.

Testing notes and safe assumptions

Use the control VIN 1HGCM82633A004352 for stable tests. It is a gasoline vehicle; EV-related fields are null, as shown above.
Do not assume drive, charger fields, or other optional attributes are present. Always null-check.
Trim strings and normalize whitespace/casing before matching manufacturer names against internal catalogs.

Troubleshooting common issues

401/403 responses: Ensure X-API-Key is present and valid. Authorization: Bearer YOUR_API_KEY is also accepted.
400-level errors: Validate that vin is exactly 17 characters. The response envelope will provide error.code and error.message if parsing fails.
Empty or partial data: Upstream data gaps return null for non-published fields. This is expected behavior, not an error.
High latency: Add a cache layer keyed by VIN. Batch decode during off-peak hours for inventory imports.

FAQ

Does the VIN manufacturer always match the make?

Not necessarily. Make is the consumer brand; manufacturer is the legal OEM entity from NHTSA data. Use manufacturer for compliance and routing, and make/model/year for display and US safety data matching.
Are recalls or NCAP ratings included in this decode?

No. The decode endpoint returns structural attributes like manufacturer, make, model, year, engine, transmission, and plant. Recalls, owner complaints, and NCAP ratings are US-market only and matched by make/model/year via their respective endpoints.
Can I get a VIN from a Dutch plate?

No. Dutch plate lookups come from RDW open data and do not include a VIN. Use VIN decoding and RDW plate lookups as separate flows.
What happens if a field is not available from NHTSA?

The field is returned as null. Your integration should treat nulls as authoritative “not published” rather than an error.
How should I cache manufacturer results?

Cache the entire decode response keyed by VIN with a long TTL. Decode data is stable; revalidate in the background if desired.

Start decoding VINs and retrieving manufacturer data in minutes. Every plan includes a 7-day free trial. Create your key now: Register.

Topics

VIN Manufacturer API API development VIN decode endpoint vehicle data integration automotive compliance solutions