0089 Posting Components Data to Luminovo

A practical Advanced ETL Processor example for building, testing, and adapting one automation workflow.

Advanced ETL Processor
4.9 ★★★★★ Based on 16 reviews on Capterra See all reviews on Capterra →

Use this example to build one working automation package, test it safely, and then adapt it to your own files, folders, or data rules. Start small. Automation is helpful; automated mistakes are just faster mistakes.

What this example does

This example prepares components data for Luminovo and posts it to the Luminovo Components API. The workflow reads a simple source file, builds the required JSON structure, groups approved manufacturers for the same item, and posts the complete component list to POST /components/import.

In practice, this is the important bit: the endpoint is a full sync. Every upload replaces the previous component import. Any internal_part_number that was sent before but is missing from the new upload is deleted on Luminovo's side. Partial uploads are not your friend here. They are more like a spreadsheet with opinions.

Luminovo components workflow example in Advanced ETL Processor

Source component data

The dummy source data contains two component types. OffTheShelf parts use manufacturer and MPN values. Custom parts use the component description and a fixed Luminovo custom part type.

ItemDescriptionUnitMPNManufacturerPartType
DUMMY-001Example ResistorPieceMPN-EXAMPLEExample Manufacturer IncOffTheShelf
DUMMY-002Example Cable TiePieceCustom

Target JSON for Luminovo

The target JSON contains one object per component. For OffTheShelf rows, the workflow writes component.data.parts[]. For Custom rows, it writes component.data.custom_parts[].

[
  {
    "internal_part_number": "DUMMY-001",
    "description": "Example Resistor",
    "component": {
      "type": "OffTheShelf",
      "data": {
        "parts": [
          { "mpn": "MPN-EXAMPLE", "manufacturer": "Example Manufacturer Inc" }
        ]
      }
    }
  },
  {
    "internal_part_number": "DUMMY-002",
    "description": "Example Cable Tie",
    "component": {
      "type": "Custom",
      "data": {
        "custom_parts": [
          { "part_type": "Other", "description": "Example Cable Tie" }
        ]
      }
    }
  }
]

Mapping logic

The mapping is deliberately strict because the Luminovo import endpoint expects different JSON branches for different component types.

  • If PartType equals OffTheShelf, build component.type = "OffTheShelf" and add each approved manufacturer to component.data.parts[] using mpn and manufacturer.
  • If PartType equals Custom, build component.type = "Custom" and add one entry to component.data.custom_parts[] with fixed part_type = "Other" and the source description.
  • If multiple rows share the same Item, group them into one component object. Do not send separate components for each approved manufacturer.
  • Use Item as internal_part_number and Description as the component description.

Grouping approved manufacturers

Multiple approved manufacturers for one internal part number must become one JSON component with multiple entries in parts[]. This is the part that catches many integrations. Sending three rows as three components with the same internal part number is a fine way to make tomorrow morning unnecessarily educational.

The workflow should sort or group by Item, accumulate all matching manufacturer/MPN combinations, and then write one final component object for each item.

{
  "internal_part_number": "DUMMY-001",
  "description": "Example Resistor",
  "component": {
    "type": "OffTheShelf",
    "data": {
      "parts": [
        { "mpn": "MPN-EXAMPLE-1", "manufacturer": "Manufacturer One" },
        { "mpn": "MPN-EXAMPLE-2", "manufacturer": "Manufacturer Two" }
      ]
    }
  }
}

Posting to Luminovo

The endpoint is:

POST /components/import

The official Luminovo API documentation states that the base URL is https://api.luminovo.com/. It also uses data model versioning through the Accept header, so check the current Luminovo API documentation before building the production request.

Because /components/import is a full sync, every scheduled run must send the complete current component list. Do not send only the components that changed. Missing items are treated as deleted on Luminovo's side.

Recommended schedule

Luminovo processes this import once a day in the early morning. The recommended upload time is around 23:00 CET, so Luminovo has the full component file ready before its daily processing window.

Rule of thumb: generate the full list, validate it, archive the JSON payload, then post it. If anything fails validation, stop the upload. A bad full sync is not a small mistake. It is a small mistake wearing platform shoes.

Videos in this example

The first video shows how to prepare JSON data for submission. The second video shows the Luminovo components data submission workflow.

Production checklist

  • Confirm the current Luminovo authentication and required headers.
  • Always generate a complete component list, not an incremental change file.
  • Validate required fields before posting.
  • Group rows with the same Item into one component object.
  • Archive the outgoing JSON payload for support and audit checks.
  • Schedule the upload around 23:00 CET unless your Luminovo process requires a different time.
  • Test with dummy data before sending production components.

Start with two dummy rows, then build up. That is less dramatic than discovering a missing component list after breakfast.

Video tutorial

Related Advanced ETL Processor resources

For more automation examples, review the Advanced ETL Processor tutorials, read the WIKI, or download the Advanced ETL Processor Enterprise trial.