For the complete documentation index, see llms.txtIntegration mappings define how Luminous data is reshaped before it is pushed to (or pulled from) an external system — Shopify, Trackstar, an EDI partner, and so on. A mapping is a list of rules; each rule reads a value from the source payload, optionally transforms it, and writes it to a field in the destination payload. This page documents the mapping engine — the field-path syntax, template syntax, the full catalogue of transformations, and the fallback mechanics. For the CRUD endpoints that store mappings, see the Integration Mappings section of the API Reference.
Two mapping formats
The engine accepts two rule formats and auto-detects which one a mapping uses by inspecting the first rule:
A mapping is treated as FieldMapper format when its first rule has both
lumField
and pushField. Otherwise it falls back to legacy processing. New mappings should use
the FieldMapper format; the rest of this guide describes it.
Rule structure
Each rule is an object with these keys:
Resolution order for a single rule:
- If
staticValueis set, use it. - Otherwise, if
lumFieldis a template, evaluate the template; if it is a plain path, extract that path from the source. - If the result is empty (
null,"", or[]) anddefaultValueis set, usedefaultValue. - If
transformationis set and the value is not empty, apply the transformation. - Write the value to
pushField.
Each rule applies at most one transformation. There is no transformation chain —
to apply several steps, use a
customFunction or a template.Field paths
BothlumField and pushField support the same path syntax:
- Dot notation —
shipToAddress.name,lumSku.customFields.brand - Array wildcard —
items[*].skuextractsskufrom every element ofitems. As a destination, it writes element-wise into the destination array. - Array index —
items[0].skutargets a single element.
Scalar broadcast
When a scalar value is written to a wildcard destination (for example a singleretailPrice mapped to variants[*].price), the value is broadcast into every
slot of the destination array. Because of this, rules that populate the array with
real per-element data (e.g. variants[*].sku) should run before scalar broadcasts
so the slot count is correct.
Template expressions
IflumField contains {{ }}, it is evaluated as a template instead of a plain path.
- Interpolation —
{{field}}, including dotted and indexed paths ({{items[0].sku}}). - Fallback chains —
{{customerPoNumber|orderNumber|'NO-REF'}}tries each field in turn and returns the first non-empty one; a quoted segment is a literal default. concathelper —{{concat shipToAddress.street1 ', ' shipToAddress.city}}.
Transformations
A transformation is applied via thetransformation key (the name) and
transformationConfig (its options). The complete supported set:
String
Number
Date
All date transforms parse the input with Carbon and return aY-m-d string. If the
input cannot be parsed, the original value is returned unchanged.
Type coercion
Lookup and extraction
valueMapping
Looks the value up in amappings table. Key matching is case-insensitive. If no
key matches, the fallback is used; if no fallback is configured, the original
value passes through unchanged.
jsonExtract
Parses a JSON string (or accepts an array/object directly) and pulls values out of it.Defaults and fallbacks
Fallback behaviour exists at several layers — they stack:- Template fallback chains —
{{a|b|'literal'}}resolves to the first non-empty field. - Rule
defaultValue— used when the resolved value is empty before transformation. valueMappingfallback— used when no lookup key matches.jsonExtractfallback/onInvalidJson— used when extraction yields nothing or the JSON is invalid.- Engine error handling — see below.
Error handling
The engine runs in non-strict mode for integration pushes: if a single rule throws, the error is logged and the engine continues with the remaining rules. A broken rule drops its field rather than failing the whole push. After all rules run, the result is cleaned:null values and empty strings are
stripped from the output payload. A rule that resolves to empty therefore
produces no destination key at all.
customFunction
customFunction runs caller-supplied JavaScript. The JavaScript is converted to PHP by
an LLM, security-scanned, cached, and executed.
- Conversion requires
OPENAI_API_KEYto be configured on the environment. Without it, only a handful of built-in patterns are recognised (price formatting, SKU padding, simple prefix/suffix concatenation, type-checked multiplication) — anything else fails. - Converted code is cached for one hour, keyed by a hash of the JavaScript, so repeated pushes do not re-call the LLM.
- The converted PHP is security-scanned before it runs. File system, network,
process execution, database, reflection, eval, and data-exfiltration calls are
blocked; the code must define a single
customTransformfunction. Code that exceeds the risk threshold is rejected and the push fails for that rule.
Reach for
customFunction only when the built-in transformations and templates cannot
express what you need. It is the most powerful option but also the slowest (LLM
conversion on a cache miss) and the most likely to be rejected by the security scan.What is not supported
- Chained transformations. Each rule applies one transformation. There is no
transformations: []array — older examples that show one are out of date. template,prefix,suffix,dateFormat,arrayMaptransformations. These names appear in older material but are not implemented. Use a template expression for interpolation/prefix/suffix,valueMappingfor lookups, and theaddDays/startOfMonthfamily for dates.- Template helpers beyond
concat. Noif, no loops, no math in templates. - Full JSONPath.
jsonExtractonly understands$[*]and$[*].fieldName. - Regex find/replace.
replaceis a literal string replacement.