Hi Kristian, this is a formatting issue on the Make side rather than on Igloo’s. Two things combine here. The value has to reach Igloo as a plain text string cut to the hour, with the offset written as +02:00. And your second error means the value still carries minutes or seconds when it arrives, which typically happens when it travels as a Make date instead of text. It also has to switch to +01:00 when Norway leaves summer time on October 25, otherwise it will break again in a month.
We fix this kind of thing every week at Getul Consulting (automation). Happy to set it up and test it in your scenario today, winter time included. Drop us a line at [email protected] and we will get it done.
Hi Kristian — is the dynamic startDate issue still blocking your live WooCommerce → Igloohome PIN flow?
If yes, I’d be interested in taking just that failing path as a small paid fix rather than changing the rest of your setup.
Before scoping it, I’d only need one sanitized failed run and the exact result you expect from a successful WooCommerce order. Then I can tell you whether it fits a bounded fix and define the pass/fail checks before any work starts.
No credentials or customer data needed for the initial check.
Hi @kristian_Bjornevik, are you still looking for help with this? I’d be happy to investigate the failing startDate mapping. Could you send the current expression and the input/error from one failed run, with private details removed? I’d compare it with the working hardcoded value first, then suggest a small paid scope. Is crypto payment an option for you?
Hi Kristian — the mapping preview can look right while the module still receives something else, so the first thing worth checking is the module’s input bundle rather than the expression preview: that shows the exact string being sent.
Two things account for nearly all of these:
Trailing precision. …T18:00:00+02:00 is fine; …T18:00:00.000+02:00 or a trailing Z usually is not, and the app’s validator rejects it even though your expression output looks correct.
The offset token. In Make, formatDate(now; “YYYY-MM-DDTHH:00:00Z”; “Europe/Oslo”) produces the +02:00 suffix; drop the Z and you get no offset at all, which many custom apps treat as invalid.
If the input bundle already reads exactly 2026-10-01T14:00:00+02:00 and Igloo still throws a RuntimeError, the fault is probably on the app side re-serialising a date object. Worth testing: feed the module a plain text value (Text parser or Aggregator) rather than a date, so nothing can re-format it on the way in.
I build Make scenarios and can look at your failing input/output bundles async in this thread — no call needed — if this is still open.
Hi Kristian, the fact that the hardcoded startDate works but the mapped value fails makes this look like a formatting/type issue rather than the date itself. I’d test what Make is actually passing to the Igloohome module, then try the API directly if the module keeps rejecting it. Sent you a DM.