AutoSync API Docs

Fitment data

Every OE fitment fits without modification to the vehicle — no lift kit or body work. See Mapping Products to Vehicles for how to use this data to filter products.

i-fitments returns a Fitments array and adds these vehicle-level fields:

StaggeredWidth and StaggeredDiameter describe whether a vehicle is a candidate for staggered wheels, not whether it left the factory with them. A 2022 Chevrolet Camaro LS has no factory staggered wheels but is often upgraded to them, so it reports StaggeredWidth: true.

i-optionalFitments returns OE optional fitments in a separate OptionalFitments array, in the same shape as Fitments.

i-plusSizes returns a PlusSizes array. Plus sizes are aftermarket wheel sizes, and the tire sizes for each, aimed at the tuning market. They are independent of i-fitments — you can request either without the other — but a plus size is only meaningful next to the fitment it shares a ChassisId with.

Chassis

Every fitment and plus size carries a ChassisId, because a sub-model alone does not uniquely identify a chassis. Vehicle 83184, for example, spans two:

ChassisId 70429  Name "19""
ChassisId 92428  Name "Ceramic Brake Package"

A vehicle typically has a few fitments sharing a chassis and several plus sizes per chassis. Match plus sizes to fitments by ChassisId — which plus sizes you offer depends on which OE fitment the user picked.

Identifying fitments

Each entry in Fitments and OptionalFitments has an Id and a ChassisId. Fitments entries also carry a Name distinguishing one option from another on the same chassis; it is often an empty string, and OptionalFitments entries have no Name at all.

Format

Format states how to read the size fields:

These are the same four values f-format and f-notFormat accept.

A U size still carries a usable TireSize string, but SectionWidth, AspectRatio, Diameter and InchWidth are all null, so match it on the string rather than on the components.

Notes

Notes on a plus size is an empty array when the fitment has no special requirements. Otherwise it holds one or more strings describing what to check, for example:

"Notes": ["Check fitment, possible clearance issues"]

Tags

i-tags adds:

ACES IDs

i-acesIds returns ACES identifiers the vehicle maps to. AcesVehicleId is the value i-acesVehicleId returns on its own, and the one f-acesVehicleId filters on. i-acesIds supersedes i-acesVehicleId — requesting both changes nothing.

A vehicle not yet mapped to ACES reports every ACES field as null.

Wheel coordinates

i-coordinates returns, for each requested vehicle angle, the box where a wheel image should be overlaid on the vehicle image. Pass a comma-separated list of up to three angles:

/vehicles?f-id=10030&i-coordinates=014,032

Leading zeros are optional — 1, 01 and 001 are the same angle.

Each requested angle adds three fields, plus InImageWheelDiameters once for the whole record:

Most vehicles have no coordinates at all, so treat the empty array and the missing Rotations field as ordinary cases rather than errors.

Reading a box

The four values are x1, y1 (top-left) and x2, y2 (bottom-right), given as fractions of the image width and height measured from its top-left corner — multiply by 100 for a CSS percentage. The first entry is the left wheel, the second the right.

x values always fall inside the image. y2 occasionally exceeds 1, meaning the wheel extends slightly past the bottom edge, so do not clamp it.

For vehicle 10030 at angle 032:

Coordinates032  [[0.44506, 0.54136, 0.52051, 0.76283],
                 [0.79318, 0.51175, 0.84218, 0.68894]]
Rotations032    [2, 1]

the left wheel is placed with:

.left-wheel {
  position: absolute;
  left: 44.506%;
  top: 54.136%;
  width: calc(52.051% - 44.506%);
  height: calc(76.283% - 54.136%);
  transform: rotate(2deg);
}

Rotations go straight into rotate(); a negative value turns the wheel counter-clockwise. Overlaid wheels line up with the original rims best when rotated this way.

Applied to a real vehicle image, the two boxes and rotations above place the wheels like this:

Both wheels here use the 0100 image, because that is what this vehicle's WheelAngles032 asks for. The boxes are not the same shape as the wheel image, so each is stretched to fill its box — set width and height independently rather than preserving the aspect ratio.

If you would rather not build the compositing yourself, VVS Express already does it — it handles the positioning, rotation and layering from these same values. See the Visual Vehicle Studio Express docs.

Which wheel image to use

WheelAngles names the wheel image angle to layer on each wheel — the same codes /wheels uses for i-img0100, i-img0200 and i-img0300:

Externally mounted spare wheels

A few vehicles carry a full-size spare on the outside. For angle 014 only, those get a third entry appended to all three arrays:

The spare is always the third entry, whatever its position in the picture — the order is left, right, spare, not left-to-right across the image.

"Coordinates014": [[0.48934, 0.63067, 0.55902, 0.84323],
                   [0.82157, 0.60554, 0.86866, 0.78670],
                   [0.16631, 0.35318, 0.23623, 0.56862]],
"Rotations014":   [2, 1, 1.2],
"WheelAngles014": ["0100", "0100", "0200"]

Angles 001 and 032 never include a spare.

InImageWheelDiameters

The wheel diameters, in inches, that visually fit the vehicle image:

The whole object is null when no diameter data exists for the vehicle.

Rear and RearMax fall back to Front and FrontMax when no rear measurement is stored, which is the case for almost every vehicle. Equal front and rear values therefore mean "no separate rear measurement", not "the axles match".

DT trims

Several DT trims can map to one vehicle. Whenever a request uses a DT parameter — f-dtTrimId, f-dtTrimIds, f-hasDtTrimId, f-dtImgUpdatedAfter, i-dtTrimId, i-dtImgUpdatedAt or s-dtImgUpdatedAt — the list holds one entry per trim, so a vehicle with three trims appears three times, differing only in DtTrimId when that is included. The page size counts entries, not vehicles. Without a DT parameter every vehicle appears once.

Rotation images

A rotation image is a spin: a sequence of stills of one tire photographed through a full turn, which you play back to let someone rotate the tire. i-img returns two things for it, alongside the five still images:

Compose a frame by joining the base, the directory and the frame number:

RotationImgUrlBase  https://storage.googleapis.com/autosync_tires/_spins/
ImgRotationDir      da8d3jfXiltyxCOV15PV9w__
frame 1             https://storage.googleapis.com/autosync_tires/_spins/da8d3jfXiltyxCOV15PV9w__/1.webp

Frames are numbered from 1, and every spin currently published runs to 36 — one frame per 10° of a full turn. Nothing in the API states the count, so treat it as a convention rather than a guarantee: tolerate a missing frame rather than aborting the sequence. At least one published spin has no frame 1 and starts at 2.

Each frame is a full-size image of roughly 70 KB, so a whole spin is a few megabytes. Load them lazily, or progressively as the user drags, rather than all at once.

ImgRotationDir is null for most tires — spins exist for a small fraction of the catalogue. On /tires you can narrow the results to only those that have one with f-hasImgRotation. /tires/models returns the same field but has no equivalent filter.

Niche tags

A niche tag links a wheel that is made for one marque or platform to the vehicles it belongs with. These are mostly replica wheels — a brand reproducing a factory design for a particular car — so they should only be offered for the vehicles they were made for.

A wheel that fits anything carries the tag N/A. NicheTag is returned by i-tags, alongside SegmentTags and VehicleTypeTags.

Filtering by niche tag

f-nicheTag is additive, not exclusive — it returns wheels with no niche tag plus those carrying the tag you name. That is what you want when listing wheels for one vehicle: universal wheels and that marque's replicas together, and nothing made for a different marque.

/wheels/styles and /wheels/filters take the same parameter with the same behaviour.

The tag comes from a fixed set, and an unrecognised value is not rejected — it simply matches nothing, leaving only the untagged wheels.

Matching wheels to a vehicle

/vehicles returns a vehicle's own NicheTag under i-tags, which is the value to pass to f-nicheTag. Note the two endpoints differ on the empty case: /vehicles reports null for a vehicle with no niche tag, while /wheels and /wheels/styles report the string N/A.

Dually wheels

A dually truck runs two wheels on each side of the rear axle. Wheels built for them come as matched sets, and Position — returned by i-specs — says which part a given wheel plays.

f-position filters on a single value and f-positions on a comma-separated list. Both are case-insensitive.

View-on-vehicle images by position

Which of the three view-on-vehicle angles a wheel returns depends on its position, because a wheel is only ever drawn where it can actually sit:

A front dually wheel is the one case that returns two 0300 paths instead of one, because the same product is photographed differently for the two axles — a full face at the front, and the deeper rear profile behind it:

Both are then composited onto the vehicle — the front face on the front axle, the rear profile on the pair behind it:

Two further details worth knowing. A front dually wheel's Img0200 comes from its rear asset rather than its own, so it already shows the rear profile. And an Inner Dually wheel returns no view-on-vehicle images at all — it sits behind the outer wheel and is never drawn.

This is also why /vehicles reports WheelAngles001 as ["0300Front", "0300Rear"] for a dual-rear-wheel vehicle where every other vehicle gets ["0300", "0300"].

LinkedDuallyWheels

Under i-specs, a Front Dually wheel also carries the IDs of the rest of its set:

"LinkedDuallyWheels": {
  "Front": 11499,
  "Inner": 189179,
  "Outer": [11503, 11500]
}

Only Front Dually wheels carry this — use it to assemble a complete set from one starting wheel.