An order importer can reject negative quantities and still lose the exact count. JavaScript's ordinary numbers have a safe integer range. A numeric value can be an integer without being a safe integer, and converting a large decimal string to a number may lose precision before warehouse validation runs.
For an interface that accepts positive whole product units, define that contract at the boundary. The following standalone example accepts safe positive numbers or canonical decimal strings. It rejects whitespace, signs, fractional units and leading zeros. Those string rules are a deliberate interface choice, not a universal warehouse standard.
const assert = require('node:assert/strict'); function quantity(value) { if (typeof value === 'string') { if (!/^[1-9][0-9]*$/.test(value)) { throw new TypeError('Expected canonical positive unit quantity'); } value = Number(value); } if (typeof value !== 'number' || !Number.isSafeInteger(value) || value <= 0) { throw new RangeError('Expected safe positive unit quantity'); } return value; } function totalUnits(values) { let total = 0; for (const raw of values) { const next = total + quantity(raw); if (!Number.isSafeInteger(next)) { throw new RangeError('Unit total exceeds safe integer range'); } total = next; } return total; } assert.equal(quantity('12'), 12); assert.equal(quantity(Number.MAX_SAFE_INTEGER), 9007199254740991); assert.equal(totalUnits(['12', 3, '5']), 20); assert.equal(totalUnits([]), 0); for (const invalid of [0, -1, 1.5, NaN, Infinity, true, null, '', '01', ' 2', '+2', '2.0', '1e3', '9007199254740993']) { assert.throws(() => quantity(invalid)); } assert.throws(() => totalUnits([Number.MAX_SAFE_INTEGER, 1])); const parsed = JSON.parse('{"quantity":9007199254740993}'); assert.equal(parsed.quantity, 9007199254740992); assert.throws(() => quantity(parsed.quantity)); console.log('Quantity boundary and aggregate checks passed'); Run the saved code with Node.js. The assertions check accepted values, rejected representations, overflow in the aggregate and a JSON number that has already lost precision. Both the individual quantity and the total are validated; individually valid lines do not guarantee a safe sum.
Number.isSafeInteger checks the representation boundary used here. MDN's JSON.parse documentation also explains that number conversion can lose precision before a reviver runs. A later check can reject an unsafe value; it cannot reconstruct the sender's original digits. If the integration needs exact values beyond this range, agree an exact representation and downstream storage contract instead of silently converting them.
This function does not establish that a requested quantity is in stock, authorize an allocation or distinguish cartons from individual units. Those are separate checks. A product identifier that happens to contain digits is also not a quantity and should not be sent through this converter.
YX Fulfillment's published integration scope includes store and order-data handovers. For such a handover, an integration review should agree quantity types and rejection behavior before imported data creates picking work. This example demonstrates a boundary check; it is not presented as deployed company software.
The real warehouse-workstation photograph provides operational context. It does not show the example running in a production system.
Warehouse workstations at YX Fulfillment.
