What is your goal?
Generate a permanent Igloohome AlgoPIN from WooCommerce that is valid immediately from the current hour.
What is the problem & what have you tried?
Hardcoded startDate works: 2026-09-24T13:00:00+02:00. But dynamic Make expressions using now / formatDate() are rejected by the Igloo module. We need the exact Make expression that dynamically outputs YYYY-MM-DDTHH:00:00+02:00.
Error messages or input/output bundles
Hardcoded value 2026-09-24T13:00:00+02:00 works. Dynamic values fail with errors such as: “startDate must be in format YYYY-MM-DDTHH:00:00+hh:mm” and "It sent seconds, but this module wants hour precision only.
Screenshots (scenario flow, module settings, errors)
1 Like
Hi Kristian, we lcome to the community.
Can you send the screenshot of the input for both modules?
Kristian, does this run for your own business, and are you looking for paid help with just the timestamp failure or the full order-to-PIN workflow? My background is production Python APIs and fault-tolerant data pipelines; I don’t have an Igloohome deployment to cite. I’d first compare the actual dynamic value with the working input and agree a small hour cap before touching the live workflow. My consulting rate is $150/hour.
Thanks, it is a nice place here. Chat GPT suggest this:
Thanks. This now outputs exactly 2026-09-25T18:00:00+02:00 in the Igloo module Input, but Igloo still returns a RuntimeError. So Make seems to generate the correct value, but the Igloo module rejects it. Could this be a validation bug in the Igloo custom app?
What do you think?
Hi Kristian, I can help troubleshoot this.
It looks like the issue is with the date value coming from Make rather than the WooCommerce trigger itself. The hardcoded value is accepted, while the dynamically formatted value is being rejected because of the precision/format expected by the Igloo module.
I work with Make date/time functions, dynamic mappings and API/module integrations, so I can help get the expression producing exactly what the Igloo field expects.
A couple of things I’d want to confirm:
-
Is the required value always the current hour, with minutes and seconds set to 00?
-
Should the +02:00 timezone be fixed, or should it follow the scenario/account timezone?
If you share the exact Make expression you’re currently using for startDate, I can take a look.
Hi Kristian, I saw your update that the dynamic value now looks right but the module still throws a RuntimeError. I’d check beyond the formatting expression at this point.
I’d compare the successful hardcoded run with the failing mapped run: input type, timezone handling, and the custom app’s validation/request body. Then I’d test the smallest change in a controlled run before touching the live WooCommerce flow.
I build API and automation workflows through Blackspire Helix. My portfolio includes a clearly labeled n8n RFQ demonstration covering validation and exception routing; I’m not claiming a previous Igloohome client deployment.
Would you be open to a small paid diagnostic with an agreed scope? A sanitized execution export and the module version would help me scope it. Please leave out credentials and real access PINs.
Carlos | Blackspire Helix
Hi Kristian — since the value now reaches the Igloohome module in the expected YYYY-MM-DDTHH:00:00+02:00 shape but still throws a RuntimeError, I’d stop treating this as only a formatDate problem.
The useful next check is to isolate whether:
- the custom Igloohome Make module is re-parsing or validating the mapped value differently, or
- the Igloohome API itself rejects the dynamic payload.
I’d handle this as a small Repair / QA sprint rather than changing the whole WooCommerce flow.
If you can share:
- a redacted screenshot of the Igloohome module fields,
- one sanitized input/output bundle,
- and whether the Igloohome endpoint can also be called through Make’s HTTP module,
I can scope the smallest fix.
For a bounded first pass, I’d propose USD 59 fixed:
- reproduce the issue on sanitized input
- compare the custom module vs direct HTTP payload
- identify the exact failure point
- provide either the corrected working mapping or a safe direct-API workaround
- short handoff note
Acceptance: the workflow generates the PIN from a dynamic current-hour timestamp repeatedly without manually editing the date.
My strongest current proof is CLEAR MERIT’s Internal / Working Demo around workflow reliability, validation and failure handling — not an external Igloohome production deployment, so I don’t want to overstate that experience.
— Kim / CLEAR MERIT
Hi Kristian, is this still open for a small paid diagnostic? Your update says the displayed date is correct but the module still rejects it, so I would compare the hardcoded and dynamic input types and error bundles before assuming another format change will fix it. Could you share the current expression and redacted input/error bundles for those two runs, plus your budget and deadline? I work remotely from Seoul in written English, using Codex-assisted troubleshooting and reproducible checks. We can agree a bounded diagnostic first, without live lock access or customer credentials.
Kristian — your update shows Make is already outputting YYYY-MM-DDTHH:00:00+02:00, but Igloohome still throws RuntimeErrors. That points more toward the mapped value/type or custom-app validation than another formatDate tweak.
I can take this as a fixed £89 async repair: compare the working hardcoded input against the dynamic bundle, trace what the Igloohome module actually receives, and provide either the corrected mapping or a small HTTP-module workaround if the custom app is the issue.
Target turnaround: within 24h after receiving redacted bundles — no live credentials needed.
If you’d like me to take it, reply here or DM QuietForgeTools.
Hi Kristian — I checked the official igloohome Make documentation.
Interestingly, igloohome itself uses formatDate(now; "YYYY-MM-DDTHH:00:00+01:00") for same-day AlgoPIN generation, with the offset adjusted to the lock’s timezone.
So if your Make input already renders correctly as 2026-09-25T18:00:00+02:00 but the Igloohome module still throws a RuntimeError, I wouldn’t keep changing the date format blindly.
The useful next step is to isolate whether the failure is:
-
the value/type passed by the Make custom module, or
-
the Igloohome API rejecting the same payload.
I can take this as one small fixed-scope repair: compare the rendered Make bundle with an equivalent API request, identify the first failing boundary, change only that part, and verify one dynamic current-hour PIN path.
If it is contained to this single issue, I can do the repair for $49 fixed.
If that works for you, send a redacted screenshot/execution showing the module input and RuntimeError. No API keys, passwords, or lock credentials are needed for scoping.
Hi Kristian,
I took a closer look at the issue, and there is an interesting point here.
Igloohome’s own Make documentation uses formatDate(now; "YYYY-MM-DDTHH:00:00+01:00") for generating a Start Date rounded to the current hour. So if your Make module is already showing exactly:
2026-09-25T18:00:00+02:00
but the Igloo module still returns a RuntimeError, I would not assume that the problem is simply the date formula.
I’d approach this as a small troubleshooting/diagnostic task:
-
Compare the hardcoded value that works with the dynamically generated value that fails.
-
Check the actual input bundle and the value being serialized by the Igloo module.
-
Verify the lock timezone and the exact Start Date requirements.
-
If the custom Igloo module still fails, test the same request through Make’s HTTP module against the Igloohome API.
-
From that comparison we should be able to determine whether the problem is in the Make/Igloo custom app layer or in the API request itself.
If you can share:
-
a screenshot of the Igloo module configuration,
-
the input/output of one failed execution,
-
the complete RuntimeError,
-
and one execution where the hardcoded date succeeds,
I can investigate this specific issue and identify where the failure occurs.
No API credentials are needed in the public thread.
Best,
Tony
Hi Kristian — there is a specific clue in your third screenshot: the Start Date input contains more than the timestamp. After 2026-09-25T18:00:00+02:00 it shows a quote/semicolon and another line of text. That suggests the format/timezone arguments may have become part of the output string. It is worth fixing that before concluding the Igloo app has a validation bug.
Rebuild the field with Make’s function picker as one formatDate call with three separate arguments: date now, format YYYY-MM-DD[T]HH:00:00Z, timezone Europe/Oslo (if that is the lock’s actual timezone). The rendered output should be exactly one timestamp, with no quotation marks, semicolon or timezone name appended. First check this in a Tools / Set variable module without generating a live PIN. Make documents the timezone as a separate third argument: Date and time functions - Help Center
For example, 25 September at 18:37 Oslo time should produce 2026-09-25T18:00:00+02:00. This is an expected-output example, not a verified run of your lock.
If you want paid help completing this, I propose US$50 fixed for this one mapping repair, verification with your controlled test, and a short handover. Scope, timing, payment and acceptance would be agreed in writing first. I use AI-assisted analysis and am not claiming an existing Igloohome client deployment. Does the unwanted trailing text disappear after rebuilding the function?
Chris | Westrock Digital | South Africa (UTC+2)
[email protected]
Hi Kristian,
If the Igloo input already shows exactly 2026-09-25T18:00:00+02:00 and only the hardcoded value works, I’d stop changing date expressions.
Next check is type and serialization: whether Make is sending a string, a date object, or a value the custom Igloohome module re-parses before the API. That would explain why two values can look identical but behave differently.
I can take this as a $49 fixed-scope diagnostic + repair:
- compare one successful hardcoded run with one failed dynamic run
- isolate whether the break is in the Igloohome module or the API
- leave you with either the working mapping or an HTTP-module workaround
- add a short note so the workflow stays maintainable
The relevant part here is API/module debugging, which I do regularly.
If it’s still open, DM me the redacted input/output from both executions. No lock credentials or API keys.
Kristian, I can help repair the WooCommerce-to-Igloohome flow. The next thing I’d compare is the exported run data from a successful hardcoded request and a failed dynamic request, including the full error, rather than just the displayed date.
Could you share those two input/output bundles with credentials, PINs, lock IDs and customer details removed? That would let me scope and quote the repair.
Thomas
Hi Kristian, I’d be interested in a small paid troubleshooting task if you want someone to take this on. I saw your update that the rendered date now has the expected format but the module still fails. I’d compare the actual successful and failing bundles before assuming another date expression is the answer.
I’ve repaired Make/API workflows with strict field requirements, including a nonprofit draft-preparation flow where malformed values had to be stopped before the provider call. For this issue I’d isolate the mapping, timezone/hour rounding and the custom module’s request handling, then test the fix with repeat runs in an approved test setup.
Could you share the current expression and the two redacted input/error bundles? Please remove API keys, lock IDs, PINs and customer details. That is enough to scope a capped diagnostic in writing, without access to a live lock.
Terry Benjamin Jr
@kristian_Bjornevik hope after reading all this AI-generated BS you still have hope for solution 
In your case it is extremely simple.
You used unnecessary " characters. Make is not Excel – " don’t have any special use case, so Make renders them with your date, e.g. formatDate({{now}};"YYYY"}} will be passed as "2026".
So your correct function is:
{{formatDate(now; "YYYY-MM-DDTHH:00:00Z"; "Europe/Oslo")}}
copy paste code above to your scenario
And if you’d rather have a human sort out the rest of your scenario, DM me or ping us through the website.
Have a nice day,
Michal
Hi, yes — the required value is the current hour, with minutes and seconds set to 00.
The timezone should follow Europe/Oslo automatically: +02:00 in summer and +01:00 in winter.
The current expression is:
formatDate(now; "YYYY-MM-DD[T]HH:00:00Z"; "Europe/Oslo")
Make outputs exactly:
2026-09-25T18:00:00+02:00
But the Igloo module still rejects it.
A hardcoded value in the same format, e.g. 2026-09-24T13:00:00+02:00, works and generates a PIN successfully.
Solved! 
Thanks everyone for the help, for pointing me in the right direction.
The working solution was to generate the date first in Tools → Set variable, which outputs:
2026-09-28T10:00:00+02:00
Then I mapped that startDate variable directly into the Igloohome module.
The AlgoPIN generated successfully and I just tested it on the physical lock — it works.
Thanks again!
Hi Kristian — I saw your latest update. If the module input now visibly contains exactly 2026-09-25T18:00:00+02:00 and Igloo still returns a RuntimeError, the remaining issue may be inside the custom Igloohome app or its API validation rather than in the Make date expression.
I can help isolate this as a small, bounded debugging task: review the module input and error context, compare the custom-module path with the documented API request shape where possible, and determine whether the failure is caused by the app schema, timezone handling or the downstream API. I would start with screenshots or a redacted bundle and would not need live credentials for the first review.
I can start with a paid diagnostic of €75, with the final price and acceptance check confirmed after seeing the redacted mapping/error. If the issue is isolated to one expression or module configuration, it can stay as a small fixed-price repair; if it is an app/API defect, I would document that clearly instead of pretending it is fixed. Could you share the current expression, the module input/output screenshot and the exact runtime error, and confirm whether you have budget approved for a paid diagnostic?
I work asynchronously in writing and would only touch a live scenario after scope and payment are agreed.
