WMS & API Integration
Without integration, every QFM runs a timer set for the slowest SKU; with it, each pallet gets its own cycle time — and documented throughput gains of 25–30% follow.
Why Integrate
Per-SKU dynamic cycle times are the single largest operational lever in a QFM room.
Out of the box, a QFM starts a cycle with a generic timer set for the slowest SKU in the building, then refines the finish from real conditions (seal quality, temperature, pauses). That is safe but conservative: fast-freezing product sits finished, occupying a blast position it no longer needs. Field cycle-time settings across operators range from 25 to 72 hours — a single worst-case timer leaves most of that spread on the table. Connecting the WMS closes it: the scanned SKU sets the cycle, and the WMS learns the moment each pallet is done.
| Improvement | Documented gain |
|---|---|
| Relocation timing alone — pulling pallets when actually done instead of on the worst-case timer | ~15% throughput |
| Full integration — per-SKU cycle times + relocation eligibility + full-occupancy management | 25–30% total throughput (given refrigeration capacity) |
The WMS-side pattern is deliberately simple: add a Freezing Dwell Time attribute to the item master; when a pallet is scanned into a known freezing position its status goes Received → Freezing (with a temporary hold), and when the cycle completes it becomes Eligible for Relocation. The pallet stays in its position until a fresh inbound pallet needs the slot — relocation orders pull from the eligible list — which keeps the freezer at full occupancy instead of half-empty between waves. Typical dwell-time mixes run 16–30 hours, so fast pallets turn fast instead of waiting on the slowest product in the room.
Integration Mechanics
One secured endpoint and a per-facility API key — set cycles, pause/resume, and read status, by unit or by zone.
Your WMS or building-automation system talks to QFM over a single HTTPS endpoint issued per facility, authenticated with your own X-QF-API-Key header. You address units by QFM serial (validated against the rack location as a safety check, so you can’t adjust the wrong unit) or whole zones by their zone ID — scoped to your own units and zones only.
GET or POST https://qfmonitoring.com/api/v1/integrations/http/{your-routing-key}
A COMMAND parameter selects the action (it defaults to set_cycle):
| Command | What it does |
|---|---|
set_cycle |
Set run time when a pallet is scanned in — pass INCUBATION (whole hours) or an ITEM_NUMBER and let the SKU library set the hours. PALLET_TAG and PO are echoed back on completion. |
pause / resume |
Hold or restart the fans. An optional DURATION (minutes) is a dead-man timer that auto-resumes if a resume is missed. |
poll |
Read the latest status, plenum temperature, ΔP, seal quality, and hours remaining. |
| bulk (POST) | POST a JSON array to act on many units in one call; each element is authorized individually. |
| zone | Address a ZONE ID to poll an aggregate (avg plenum temp, ready/running/offline counts, good-seal %) or pause/resume every unit in the zone. |
Every unit call carries QFM_SERIAL and RACK_LOCATION; a poll returns the unit’s current status, one of:
| STATE | Meaning |
|---|---|
READY |
Ready for a pallet |
SEAL_TEST |
Cycle started, seal test in progress (up to 5 minutes) |
RUNNING |
Seal test passed, cycle running |
BAD SEAL |
Ran 5 minutes without achieving an acceptable seal |
PAUSE |
Paused by controls or schedule — fan and timer stopped |
COMPLETE |
Cycle finished, pallet still present |
BLOW_OUT |
Post-completion blow-out running after pallet removal |
BOOT_UP |
Initializing — about 2 minutes after power-up |
MOTOR_FAILURE |
Fan motor fault — service condition |
SENSOR_FAILURE |
LIDAR or temperature sensor fault — service condition |
You do not have to poll: cycle completion can also be pushed — QFMonitoring sends a “cycle done” message to the WMS, in addition to the SMS/email notifications, dashboard status, and the unit’s LED. Most integrations use the push for workflow and the poll for reconciliation.
Design pitfall — serial-to-location mapping accuracy. The integration is only as good as the QFM_SERIAL ↔ RACK_LOCATION mapping: a wrong mapping means setting cycle times on the wrong unit. QuickFreeze supplies the mapping as a spreadsheet, and each unit’s metadata (rack location, circuit order) is assigned in the field via the QR-code form on the side of the unit. Validate before go-live — triggering units one at a time by location code and confirming the physical unit responds is the proven check.
This is the overview. The full reference — copy-paste request/response examples for every command, the bulk and zone calls, the callback payloads, and the rejection reasons — is in the QuickFreeze QFM API Guide →. Your routing key, API key, the serial↔location map, zone IDs, and a test sandbox are issued at integration setup.
SKU Libraries
The dwell-time knowledge base that makes per-SKU cycles work.
The QFM dashboard maintains a SKU Library — pre-populated from the SKUs actually located in your rooms — where each item carries its dwell hours, customer, and description. Paired with a WMS integration, the library automatically adjusts QFM run times based on the SKU scanned to the unit, with no operator timer management. Dwell values come from three sources, in rising order of confidence: the customer’s existing standard, the storage commodity-code manual, and on-site time studies of the actual product. Start with what you have; the logged cycle data sharpens the numbers from the first week of operation. (For what drives the hours themselves — solution percentage, case weight, room temperature — see Section 1 and the Heat Load Calculator.)
Process and Commercial Terms
Four steps, about a month of calendar time, and a budgetary price of zero.
| Phase | What happens | Duration |
|---|---|---|
| 1. Scoping call | Workflow defined end-to-end (swimlane diagram): which scans trigger which calls, who notifies whom | 1 call |
| 2. Parallel build | QuickFreeze configures the integration endpoint and mapping; your IT builds the WMS side | Concurrent |
| 3. Sandbox integration | Joint testing against a sandbox before any production unit is touched | ~3–4 weeks |
| 4. Go-live | Mapping validated, push notifications confirmed, production cutover |
Cost: QuickFreeze is currently not charging for integrations — the budgetary number is $0.00 — with one reservation: the right to rate-limit if request volume becomes excessive. There is no per-call fee and no subscription tied to the API itself.
Documents & Related Reading
The network prerequisites, the unit spec, and the live dashboard.
Network Requirements
Integration presumes connected units — the firewall and DHCP requirements every QFM needs first.
QFM Spec Sheet
The unit itself — dimensions, mounting, and the hardware your serial numbers refer to.
Sample Dashboard
The monitoring layer your integration runs alongside — SKU Library, unit states, and notifications.
Integration FAQ
Asked by WMS and EDI developers on real integrations.
Is the API REST with POST/PUT verbs?
The integration contract is HTTP GET with URL parameters over SSL, authenticated by a per-customer header; the server responds 200 on success. It is deliberately minimal — two calls (set cycle time, poll state) cover the standard workflow. Anything beyond the standard contract is defined at the scoping call.
Is there a sandbox before we touch production units?
Yes — sandbox integration is a formal phase of every rollout, typically quoted at 3–4 weeks, and go-live does not happen until the joint testing and mapping validation pass.
Can completion push to our WMS instead of us polling?
Yes. When a cycle finishes, QFMonitoring can send a cycle-done message to the WMS, alongside the SMS/email notification, the dashboard update, and the unit LED change. Poll the state endpoint for reconciliation rather than as the primary signal.
What does the integration cost?
The budgetary number is $0.00 — QuickFreeze currently does not charge for integrations. The one reserved right is rate-limiting if request volume becomes excessive, which a sanely scheduled WMS will never hit at ~1 call per pallet event.
How do we trust the serial-to-location mapping?
QuickFreeze provides the QFM serial ↔ rack location mapping as a spreadsheet, and each unit’s location metadata is set in the field via the QR-code form on the unit. Validate it before go-live by commanding units individually by location code and physically confirming the right unit responds — mis-mapping is the one failure mode that silently freezes the wrong pallet on the wrong clock.
Schedule an Integration Scoping Call
One call defines the workflow; your team and ours build in parallel from there.