JLR Configurator Source

The JLR configurator source fetches vehicle configuration data from the JLR public configurator JSONP API. Two base URLs serve the two brands:

• rules.config.landrover.com — Land Rover (URL path contains /lr/)
• rules.config.jaguar.com — Jaguar (URL path contains /jag/)

Fetch chain

Three resources are collected in sequence, each feeding the next as upstream:

1. vehicle_list — one GET per brand URL. Returns every active nameplate x model-year combination with a version-forwarding href.
2. root_config — one GET per vehicle-list entry ({href}/.jsonp). Contains the full feature dictionary for the nameplate, including all PRODUCT definitions. This is the sole source of model entities.
3. body_style_configs — one GET per PRODUCT (using the PRODUCT's query[0].href). Contains features scoped to that specific product configuration. This is the sole source of feature entities.

Brand derivation

brand is derived from the API URL path, not from response properties:

• /lr/ in the href → "Land Rover"
• /jag/ in the href → "Jaguar"

The BrandFamily property (e.g. "Range Rover", "Discovery", "Defender") is stored separately as brand_family. It is a sub-brand within Land Rover, not the OEM brand.

Both brand and brand_family are propagated to all entities (models, features, dealers, inventory).

PRODUCT decomposition

A PRODUCT is a fully specified vehicle: one MODEL x one ENGINE x one BODYSTYLE x (optionally) one FUEL_TYPE. The product_id is the PRODUCT feature's id (lowercased).

Each PRODUCT's property.definition is a space-separated token string decomposed against the feature dictionary:

Token position	Lookup	Entity field
First	Always BODYSTYLE	bodystyle_id
Remaining	Feature dictionary MODEL category	model_id
Remaining	Feature dictionary ENGINE category	engine_id
Remaining	Not in dictionary	fuel_type (uppercased)

The feature dictionary is built from the root config's BODYSTYLE, MODEL, and ENGINE categories. Each decomposed component's description is looked up from the dictionary to populate human-readable fields (body_style, engine).

Model extraction (extract_models)

Models are extracted from root_config only. Per PRODUCT in the root config response:

• product_id — PRODUCT feature id (the entity key, with programme_code and model_year_code)
• model_name — marketing name derived from vehicle description and BODYSTYLE description
• trim — suffix of the MODEL description after stripping the nameplate prefix
• msrp — PRODUCT feature's price.GROSS.value
• manufacturer_model_code — DerivativeModelCode property (join key to inventory)
• code_5000 — 5000Code property
• derivative_pack_code — DerivativePackCode property
• bodystyle_id, engine_id, model_id, fuel_type — from PRODUCT decomposition
• body_style, engine — descriptions from feature dictionary lookup

Feature extraction (extract_features)

Features are extracted from body_style_configs only. Each body_style_config request is scoped to a single PRODUCT, with product_id passed in request context.

All categories in the feature dictionary are extracted except:

• BODYSTYLE, MODEL, ENGINE, PRODUCT — structural categories, not user-facing features
• CHARGES — pricing metadata
• CURATEDCHOICES — curated bundles, not individual features

Each feature record includes feature_id, brand, name, category, subcategory, price, description, availability, jlr_code, programme_code, model_year_code, product_id, and model_year.

Entity keys

Entity	Key fields	Source
models	programme_code, model_year_code, product_id	root_config
features	programme_code, model_year_code, product_id, feature_id	body_style_configs

Known data quality issues — configurator_models

code_5000 — opaque derivative code differs across model years

Observed: 2026-07-13

code_5000 is sourced from the 5000Code property on each PRODUCT feature. The same product_id can appear across multiple model years (e.g. k25, k26, k27), each carrying a different 5000Code. The field is not used in joins or downstream business logic.

derivative_pack_code — differs across model years

Observed: 2026-07-13

derivative_pack_code is sourced from DerivativePackCode. Like code_5000, it varies across model years for the same product_id. Its exact semantic meaning has not been confirmed by external documentation.

manufacturer_model_code — join key varies across model years

Observed: 2026-07-13

manufacturer_model_code (DerivativeModelCode) is the join key between configurator models and NetDirector inventory (modelCode). Different model years for the same product_id can carry different values (e.g. AT663 from MY2025 vs GF663 from MY2027). Since model_year_code is part of the entity key, these are distinct records — not conflicts.

msrp — base price differs across model years

Observed: 2026-07-13

msrp is the PRODUCT's GROSS base price. It varies across model years for the same product_id as pricing changes between model years. Since model_year_code is part of the entity key, these are distinct records.