Tire API v1.6.0 Changelog: Factory Lug Torque

Tire API v1.6.0 adds a new endpoint aimed squarely at the fitting bay rather than the catalog. Every previous endpoint answers "what size fits this vehicle?" This one answers a different question: "what do I torque these to?"

New Endpoint: GET /oem_specs

What It Returns

Factory fastener torque for a vehicle, in foot-pounds, alongside the OE fitment's load index, speed rating, and Extra Load (XL) marking. This data has existed in our upstream pipeline for months and simply wasn't reachable through the API until now.

Endpoint Details

  • HTTP Method: GET
  • Full Path: /api/v1/oem_specs
  • Authentication: x-api-key header
  • Access: any paid plan — Starter, Pro, or Business. Free returns 403 Paid subscription required. This is not a Business-only endpoint — that distinction belongs to /search_allsizes.
  • Parameters: year, make, and model are required; trim is optional. Omitting trim is the common case and returns every trim for that vehicle, since torque frequently varies by trim and callers often don't know the exact trim string.
  • Quota: none. No monthly allowance, no quota headers, no new block on /usage. It runs on your existing daily request limit only, the same as /tire_dimensions.

Request Example

curl -H "x-api-key: your-starter-key" \\
  "https://tire.vdim.app/api/v1/oem_specs?year=2021&make=Ford&model=F-150"

Response Shape

data is always an array, one row per trim/size combination:

  • trim — the vehicle trim this row applies to
  • tiresize — the OE fitment these specs apply to
  • torque_ft_lb — factory fastener torque, in foot-pounds (see below)
  • fastener_type — "lug_nut" or "center_lock"
  • load — load index for the OE fitment
  • speed — speed rating letter
  • xl — Extra Load / reinforced marking, null when not applicable

Why About Half the Rows Come Back With No Torque Value

This is the part of the release worth understanding, not just the endpoint itself.

At launch, 48,118 of 107,291 fitments (44.8%) carry a published torque value, and that number is growing as we backfill. The other roughly 55% return torque_ft_lb: null.

That's a deliberate design decision, not a gap. Our upstream pipeline withholds a torque figure whenever its sources disagree, because publishing the wrong number is more dangerous than publishing none — under-torque is a real wheel-loss failure mode. A null here means "not published for this fitment, consult the vehicle manual". It never means zero, and it never means the lookup failed — the row still comes back with everything else populated. A genuinely unknown vehicle is a separate 404.

If you're building a UI on top of this endpoint, render null as an explicit "not available, check your owner's manual" state — not as 0, not as a dash, and don't just omit the field.

One more distinction worth carrying into any UI: not every value is lug-nut torque. Centre-lock hubs use a single central nut at a much higher torque than a lug nut, and fastener_type tells you which you're looking at. A field labelled generically "lug nut torque" would be wrong on those rows.

And as with any spec API, this is a convenience layer, not the final word — the manufacturer's own service manual is the authority. Values here are given in foot-pounds; there's no unit conversion built into the API.

A Header Name Fix You May Need to Act On

Six items shipped in this release are documentation and sample corrections — no endpoint behavior changed, and no response shape moved. The one worth acting on: the JS, curl, and Python code samples on /api/v1/docs previously showed X-RateLimit-Daily-Remaining and X-RateLimit-Plan as response headers. Neither of those has ever existed. The real header names are X-RateLimit-Remaining and X-Subscription-Type. If you copy-pasted that sample into your own code, it's been silently reading undefined — worth a quick check.

The other five corrections are lower-stakes documentation fixes: the /search_allyear, /search_allwidth, and /search_allmake docs now correctly show data as an array (it always was — only the docs were wrong); the shared error response docs now match what the API actually sends; the /by_size docs now list the correct valid path values; and the TireDimensionsResponse schema now correctly documents dimensions as an array. None of these reflect a change in what the API returns — only a change in what the docs said it returns. Worth noting: /by_vehicle and /by_size still return data as an object keyed by index ("1", "2", etc.) — that's unchanged and intentional, and applies only to the three /search_all* list endpoints that were mis-documented.

Docs & Spec Updates

  • OpenAPI bumped to 1.6.0 with the full /oem_specs path, a new response schema, and two named examples — one populated, one showing the null-torque case
  • The public code samples now reference the real rate-limit header names
  • The in-app docs JSON documents the null and fastener_type semantics directly
  • The API guide, Help Center, and FAQ are all updated to include the new endpoint

No Breaking Changes

v1.6.0 is fully backward compatible. No existing response shape changed — every item beyond the new endpoint is a documentation or sample fix, not a behavior change.

Trying It Out

Support & Resources

Need help? Contact support at support@vdimtech.com or visit the API portal at https://tire.vdim.app for interactive documentation.

Conclusion

OEM specs is our first endpoint built for the counter and the fitting bay, not just the catalog page. It won't have a number for every vehicle yet — and that's by design, not by accident — but where it does, it's one call away, on every paid plan, with no quota to track. If you copied the old rate-limit header sample, that's the one thing from this release worth checking today.

Tags

API Changelog Tire API Release Notes REST API Vehicle Data OEM Specs Torque