Chat ID: 6b61a21b-d955-4c46-9a74-b71f2e71721c Timestamp: 3 August, 2025, around 9:30 NZT (this is specific enough?) Expected response: AI agent is able to accurately check my calendar availability and book an appointment using conversational prompts Response received: When VAPI AI agent tries to check my calendar availability, it ends up not finding a free slot because it keeps using a time in the past Hello there, How do I ensure that my VAPI AI agent uses the current time when checking for my availability in my GoHighLevel calendar? For context, the AI is able to check existing contacts and create new contacts in GHL. However, whenever my VAPI AI agent checks my calendar availability in GoHighLevel, it has a very high probability of using a date from the past. At the start of my prompt, I have already asked the AI to check the current time via the following: # Important Check the Current Date and Time when starting the call: The current date and time is: {{"now" | date: "%b %d, %Y, %I:%M %p", "Pacific/Auckland"}}" Also, when I 'spoon-feed' the exact date to the agent, it is able to make the booking (see third attached image). But, when I use less specific language such as "Monday, 10AM" or "Tomorrow, 10AM", it starts getting confused - specifically when finding a free slot. Thanks for your time!

If that liquidJS is not working for GHL, try using {{date}} instead as some users have reported that format to be fetching the correct dates with that in their prompt.

Thanks, Kyle and I hope you don't mind the late response. I found a similar thread from a few months ago that recommended adding this into the main prompt (see below). This appears to work for me. I have modified it a bit to fit my purposes (New Zealand). When calling get_free_slots: STEP 1: Calculate target date from user request - "Tuesday at 3 PM" → May 27, 2025 STEP 2: Convert to epoch milliseconds for full day - startDate: May 27, 2025 at midnight (beginning of day) - endDate: May 27, 2025 at 11:59:59 PM (end of day) STEP 3: Call tool with calculated values - calendarId: "w02SZbEtgyKbXHfr9l2O" - timeZone: "Pacific/Auckland" - startDate: 1748284200000 (13-digit number for May 27 start) - endDate: 1748370599999 (13-digit number for May 27 end) CRITICAL: Always calculate new timestamps. Never reuse 1717036800000 or other old values.

That's great to hear! I will be sure to note this down for our other users having this issue. If you need anything else, please let us know