What changed

Luminous custom fields with a Number type now return their value as a JSON number (e.g. 19.97) rather than a string (e.g. "19.97") across all read surfaces:

  • External V1 API — the custom_fields object on product and other entity responses
  • Product export endpoint (/products/export cursor-based dump)
  • Catalog-push grid — the custom-field columns displayed when reviewing products to push
  • Automation script preview — the _customFields payload shown in the preview panel. Note: this one surface is an exception — ScriptPreviewController explicitly casts the resolved value to a string before including it, so a Number field still appears as a numeric string here (e.g. "25.5"), not a JSON number. If your script logic depends on the type, don't rely on this surface matching the others.
  • PDF export templates — invoices, packing slips, and other HTML templates using custom-field placeholders
  • SKU spreadsheet download — the custom-fields summary column

Previously, if a number-typed custom field's value had been imported into the text storage column (a common pattern for prices and freight amounts), read paths that prioritised text would surface a string, while read paths that only checked the numeric column would return blank. Either way, the result was inaccurate.

The fix applies a consistent resolver for Number fields:

  1. If the numeric column holds a value → returns it as a float.
  2. If only the text column holds a value and that text is a valid number → coerces it to a float.
  3. If the text column holds non-numeric content (e.g. a date-shaped value like 3/8/00) → returns null rather than surfacing incorrect data.

Do I need to update my integration?

If you consume Number custom fields via the External API, check that your code handles a JSON number type. Most API clients (Python, JavaScript, etc.) parse JSON numbers natively, so no change is needed. However, if your code explicitly called parseFloat() or str() on the value expecting a string, it may need a small update.

What if a field that was previously blank now has a value?

This is expected. Fields whose values were stored only as text (and previously returned as blank because the numeric column was empty) now correctly return their numeric value via the fallback coercion.

What about date-shaped values that are now blank?

If a number-typed field previously showed a date-looking string (e.g. 3/8/00) and now shows blank, the stored text was not a valid number. Luminous treats those as data corruption and suppresses them. Contact support if you believe a specific field's data needs to be recovered.