TME Electronic Components Catalog & API

Most component data makes you infer a distributor's actual warehouse position from aggregated third-party listings. This dataset is the opposite bet: one distributor, its own numbers. Transfer Multisort Elektronik - TME - is a major European electronic component distributor whose offer runs to roughly 1,500,000 products from more than 1,300 suppliers, spanning Semiconductors, Embedded and IoT systems, Optoelectronics, Light sources, Passives, Connectors, Fuses and Circuit Breakers, Switches and Indicators, Relays and Contactors, Transformers and Ferrite Cores, Power Sources, Wires and Cables, Enclosures, Automation, Pneumatics and Hydraulics, Robotics and Prototyping.

One record covers one product symbol, and it is satisfyingly complete: unit price, stock quantity in the TME warehouse, a typed availability status, the part's category-specific parameter set, and its document list. Parameters arrive as plain label/value pairs - a laboratory power supply declares "Type of laboratory power supply programmable", "Kind of power supply single-channel", "Number of channels 1" - and documents are typed too, from manuals and documentation through safety data sheets and warranty terms.

That first-party shape is the whole point. Aggregators tell you what several distributors claim; this tells you what one warehouse actually holds, at European scale, with lead times attached. Get a sample of this dataset and start with the availability records - they read like a distributor's nerve endings.

Availability first, quoted from a published response exactly as it stands:

status         : AVAILABLE_IN_STOCK             amount : 647

status         : DS_DELIVERY_NEEDS_CONFIRMATION amount : 353
waiting_period : P5W                            supply_date : 2026-06-17

Two lines, two completely different procurement situations: 647 units on the shelf versus 353 units behind a five-week wait with a named supply date. Descriptive fields ride along per symbol; the block below assembles each field's documented example value so the full record shape is visible:

symbol         : PPS-3020      price           : 41.4    country : GB
parameters     : Number of channels = 1
files          : DTE - Documentation PDF
mpn            : ESP8266EX     manufacturer_id : 259     category_id : 113180

Read the two blocks together and the design shows itself: identity fields locate the part, price and country scope the commercial context, and the availability object turns shortage into a chartable lead time instead of a shrug.

Ten fields form the verified spine of a record - every definition below is confirmed, not guessed. Identity keys (symbol, mpn), commercial context (price, country), warehouse truth (amount, status) and the descriptive payload (parameters, files, manufacturer_id, category_id) all travel together, one row per product symbol.

A handful of further attributes are known to exist in the wider schema - links to related and similar parts, resolvable manufacturer names, the fuller document-type set - but their exact delivered shapes deserve confirmation against a real extract rather than confident prose. They sit itemized in the final row of the table.

Geography - Europe-focused distribution with country-scoped offer and pricing context: each record resolves against a chosen country (GB in the worked example), backed by localized storefronts across many European languages. Treat it as a continental panel you can slice per market, not a global average.

Temporal - this is a current-position catalog, not a dated archive: each record speaks to the warehouse now, and forward-looking fields carry the future instead - supply dates (2026-06-17 in the published sample) and waiting-period windows (P5W). Historical depth comes from how long you collect, which is a scheduling decision rather than a property of the source.

Granularity - one row per product symbol: price, stock amount and status, parameter set and document list. Per-part resolution is precisely what pricing models, BOM costing and availability monitors need; aggregates would average away the exact variance they run on.

API, files, or your warehouse. Daily, weekly, or hourly.

• Price and availability monitoring - watch one distributor's European warehouse position part by part, with shortages expressed as waiting periods and supply dates rather than bare zeros.
• BOM costing and sourcing - pull unit prices scoped by country and currency for a full bill of materials, then re-run the same pull when quotes come due.
• Demand-signal research - read stock amounts and lead-time windows across 1.5 million parts as a high-frequency indicator of European electronics demand.
• Catalog and taxonomy work - mine 1,300+ suppliers' worth of category-specific parameter pairs to benchmark how component families describe themselves.
• Competitive intelligence - track where a single major distributor commits shelf space versus allocation, category by category; more framings on our competitive intel product teams use cases page.

Developers and data-product builders get a compact, stable per-symbol schema with typed statuses that drops straight into availability dashboards and alerting pipelines. Data scientists and ML engineers get 1.5 million parts of price, stock and parameter texture - rare, labeled, first-party ground truth for demand and pricing models. E-commerce operators and sourcing teams get a European stock check before promising a build or a ship date. More angles on our best electronic components datasets ranking.

Three things. First, this is a live catalog, not a retrospective archive - the source speaks in current positions and forward supply dates, so if your study needs trailing history, say so and let scheduled collection accumulate it at your chosen cadence.

Second, parameters are deliberately category-specific: a laboratory power supply declares channel counts, a connector declares pitch. Expect sparsity when you join across families and lean on the category tree rather than pretending one parameter column means the same thing everywhere.

Third, the ten-field spine above is verified; a few wider-schema attributes are listed as pending confirmation in the dictionary's last row because we would rather confirm them against a real extract than hand you confident guesses. Request a sample and we will resolve exactly those cells.