Skip to main content

MENA Net Director Source

The MENA sources fetch model catalogs, per-variant feature catalogs, inventory listings and dealer locations for the Middle East and North Africa markets. Mercedes serves these markets through Net Director, a different platform from the NAFTA web APIs. The client modules live in packages/ai_public_api/src/ai_public_api/mercedes/mena/.

Authentication

No per-partner credentials. The configurator endpoints share a single static x-api-key taken from the public web widget; the listing and locations endpoints use a static UUID and auth-token pair. All of these are public values served to any browser loading the site.

Endpoints

SourceEndpoint
nd_configuratormercedes-configurator.netdirector.auto — filter classes, selectables names, per-baumuster selectables
nd_listingproduction-api.search-api.netdirector.auto/api/vehicle-search (getCount + getAll)
nd_locationsgetAllLocations GraphQL query

Endpoints deliberately not used

EndpointWhy
search-api.netdirector.auto/v3.5/search/<softwareId>/buy-new (REST)Serves the same vehicles as the GraphQL search in a different envelope.
extras.api.netdirector.auto/api/extras/<groupSoftwareHash>Dealer-fit warranty and protection plans, not factory-fit equipment.
finance.api.netdirector.autoPer-stock finance quotes; nothing the raw tier needs.
Vehicle detail page HTML (/<country>/en/stock/<stockId>-…/)equipment[].label on the listing carries the same item set, so scraping the page costs roughly 1,170 extra requests per partition and yields nothing new.
Buy-new page DOM (data-vehicle-context cards)The GraphQL listing covers the same data far more cheaply.

Markets

MENA_MARKETS maps each market's URL slug to its ISO country code. The slug is the canonical key: Dubai and Abu Dhabi are separate listing markets but resolve to one configurator fetch, so listing granularity and configurator granularity differ.

Eight markets carry stock — Dubai, Abu Dhabi, KSA, Qatar, Kuwait, Bahrain, Oman and Lebanon — totalling roughly 1,170 vehicles. Jordan, Iraq and Palestine serve an empty Net Director shell from their buy-new pages and so have listing_active=False; a discovery pass over MENA should re-probe them in case stock appears.

The configurator locale is <language>_<country>, and the country half filters which models appear: Qatar's catalog holds 45 baumusters against UAE's 73, and Saudi carries one model UAE does not. The language half localizes display strings only.

Inventory listings are English whatever locale is requested — the endpoint takes no language parameter and ignores Accept-Language. The Arabic MENA pages translate client-side, so no server-side Arabic inventory text exists to collect. Arabic catalog-level strings do come from the configurator under ar_* locales.

Stock scope must be scraped

There is no public endpoint returning a market's GraphQL stockScope. It is reconstructed by fetching each country's /buy-new/ page and decoding the base64 data-js-context blob embedded in the HTML.

Configurator quirks

  • The views parameter accepts only one value. ALL, OPTIONS, DETAIL and the rest all return HTTP 400.
  • The selectables-names URL preserves an upstream typo, seletables with one l. Correcting the spelling breaks the request.
  • A configurationId can contain literal # characters, which must be URL-encoded.
  • The per-baumuster feature catalog returns roughly 350–413 components per variant in a single unpaginated response.
  • Lebanon, Jordan, Iraq and Palestine return a 65-byte stub rather than a catalog.

Feature sources

Three sources carry feature data at different levels:

  • nd_listing's equipment[].label is the per-vehicle factory specification, and features is a controlled keyword vocabulary (AIRCONDITIONING, ALLOY, UPHOLSTERYLEATHER) populated on every vehicle.
  • nd_configurator selectables is the per-baumuster catalog: each component carries its code, taxonomy, selected/standard/fixed/hidden flags, images and price information. Every response is split client-side into one row per vehicleComponents entry with the envelope preserved on each row, which keeps a row around 11 KB instead of 600 KB and the table browseable from a SQL client. Roughly 900 HTTP calls per partition expand to about 310,000 rows.
  • nd_configurator selectables-names is a region-shared dictionary of roughly 4,200 OEM codes to English labels. Selectables reaches about 45% of them; most of the remainder are engineering and pre-installation codes that never surface in MENA, but a handful of customer-facing Digital Extra: … codes appear only here. The endpoint has no Arabic equivalent.

Fields the schema exposes but MENA leaves null

The Vehicle type exposes 102 fields and the listing query requests all of them, so a future MENA population change surfaces without a query edit. These are consistently null across sampled MENA vehicles:

  • Tech specs — engine.*, performance.*, technical.acceleration, maxSpeed, the efficiency values, emission.*, dimensions.*, weight.*, ncap.*.
  • Per-VIN option codes — equipment[].code, identifiers.baumuster, nccConfigId, mpvCode, oemVehicleCode, cap, wheel, upholstery, interiorDescription, colour.exteriorRoof.
  • Order dates — consignmentDate, purchaseAtDate, availability.leadTime.

range.* and electricAttributes.* are null on the petrol vehicles sampled and untested against a BEV.

Two consequences follow from the missing per-VIN option codes. The selectables-names dictionary has no join key onto inventory, so it stands alone in raw. And Cosy renders are unreachable, because they are keyed by baumuster plus option codes — a vehicle's images array holds dealer-uploaded photos on Net Director's S3 bucket instead. Wheel, upholstery and trim descriptors are recovered in the transform tier by keyword extraction over equipment[].label and colour.interior.

No MENA endpoint prices an individual option: the listing options preview, the configurator and the detail pages all omit per-option prices.

Dealer hierarchy

Every vehicle carries its rooftop's location block — hash, full address, coordinates, phoneNumber, openingHours — alongside top-level groupHash, franchiseHash and companyHash[]. The dealer entity can therefore be built at rooftop, group, franchise or company level; per-rooftop keyed on location.hash with the other three hashes denormalized for downstream rollup is the shape to prefer.

A country's stockScope names hashes at whichever level that market routes through, so it bounds rooftop count from below rather than stating it — Dubai's scope alone covers 9 rooftops, while several countries route through a single franchise or group with an unknown number underneath. The real count comes from distinct-counting location.hash over the listing rows.

Why locations has its own source

The listing feed only names dealers that currently hold stock. getAllLocations returns every rooftop, including service centers and certified pre-owned showrooms that never appear in inventory-derived dealer data.