Hey — I’m using Vapi with the Google Calendar tool and running into an issue. When I ask the assistant to check availability for “tomorrow at 3pm,” it keeps using the wrong date (like saying today is June 16th instead of the actual current date) (See screenshot). Because of that, it always returns incorrect availability even though my calendar has events. I even tried moving the logic to a Make.com webhook to fix it, but the Assistant is still sending the literal placeholder string {{dateTime}} or the wrong date string to my webhook, so the calendar check always returns the wrong info. How can I force the Assistant to be grounded in the real current date and time so that "tomorrow" actually means the real tomorrow? Is there a system variable I'm missing? Right now this makes the entire booking flow unreliable. https://cdn.discordapp.com/attachments/1506677747961827388/1506677748163412150/image.png?ex=6a0f227f&is=6a0dd0ff&hm=d5d80854eb3bee03dc8222f82157d7d809541b82c8d1359f6f64bb37840d3dda&

This usually happens when the agent isn’t actually getting a real-time clock, so it starts guessing or using placeholders like {{dateTime}}. The fix is to pass the current time from your server (ISO format) into the tool call so “tomorrow” is always computed correctly outside the model. Are you pulling the time from Make, or letting Vapi handle it right now? @Ryan

ideally i want everything to pull from google calendar integration. i added this in the prompt ### SYSTEM TIME - Today's date is {{now}}. and it seems to work correctly. However when I ask if there's an availability at 3pm it says yes even though I have it blocked off. So its pulling the correct google calendar date now but not entirely syncing the calendar. It even booked the appointment for me but it just double booked the time. https://cdn.discordapp.com/attachments/1506677747961827388/1506683994052497518/image.png?ex=6a0f2851&is=6a0dd6d1&hm=0830c6edb47f0e28c6b65364263373a10a9888b6e1cff77014972a8f6061407e&

You’re very close, the issue isn’t {{now}}, it’s that “tomorrow” isn’t consistently being converted into a fixed ISO date before the Google Calendar call. That’s why it sometimes checks or books the wrong day even though the prompt date is correct. The fix is to handle all date resolution outside the LLM (Make/Vapi layer) and only send absolute timestamps to Google Calendar, not relative terms. Are you currently converting “tomorrow/3pm” in Make, or letting Vapi handle that part?

@Ryan I would suggest you to converting dates and times like this outside vapi

Still stuck. Here's exactly where I am with full details: What's working: Vapi correctly sends requestedDay: "today" and requestedTime: "15:00" to Make webhook Webhook receives both values correctly Google Calendar has a confirmed event "Test Blocked" at 3–4pm today on the GoodFellas Demo calendar What's broken: Google Calendar module in Make throws BundleValidationError, Invalid date in parameter timeMin and timeMax I've tried every date formula I can find: parseDate, addHours(startOfDay(now)), formatDate, all fail with invalid date errors When it does pass through, it returns busy: [] even with a confirmed event blocking that time My Make setup: Module 1: Custom Webhook (receives requestedDay and requestedTime) Module 2: Google Calendar → Search Events Module 3: Webhook Response Calendar ID: c_6b0fd81b1ee62d9edd907b45edf005c82f3e2920349f73c46d990bc7c82dc3b0@group.calendar.google.com Timezone: America/Phoenix What I need: Can you share the exact working formula for timeMin and timeMax in the Make Google Calendar Search Events module when receiving requestedDay ("today"/"tomorrow") and requestedTime ("15:00") from a webhook? Nothing I've tried produces a valid date that Google Calendar accepts.

Handling dates and times are really hard just with vapi it can guess but can't be accurate... I made multiple automations for booking, but vapi gets these dynamic requests like tomorrow / today...!!

So then your suggesting I use make for more accuracy? If so what do you do to get it to work because its still not syncing with my calendar. It will say its available and book the time slot but it will just double book the spot and add two meetings instead of saying that time slot is full.

yeah making google calendar integration is really hard, i have a few templates message me if you want to get access to it...

You’re basically running into two problems at once, Make isn’t producing valid timeMin/timeMax, and Vapi isn’t reliably stopping double bookings. The key fix is to stop using any relative time and always build clean ISO start/end times in Make before calling Google Calendar. When you see “busy: []” even with events, it usually means the time window or timezone isn’t matching what’s actually on the calendar. At this point, use Make only to handle the date and availability check, and let Vapi just trigger the process. @Ryan

I tried building clean ISO start/end times in Make before calling Google Calendar like you suggested but still getting BundleValidationError — Invalid date in timeMin and timeMax on the Search Events module. I've tried every formula I can find including parseDate, addHours(startOfDay(now)), formatDate, and even hardcoding a static date like 2026-05-20T15:00:00-07:00 — all throw the same invalid date error. The webhook is receiving the data correctly (requestedDay: "today", requestedTime: "15:00") but nothing I put in the Google Calendar date fields is being accepted. What exact format does the Make Google Calendar Search Events module expect for timeMin and timeMax? Can you share a working example?

{{"now" | date: "%A, %B %d, %Y, %I:%M %p", "America/Los_Angeles"}} edit the zone 'america/los'... To your precise location Use this time format in your prompt... Put clear description for your assistant to use this for your current date and time...

Hey, I'm investigating your issue. Can you please provide the call ID? I can check our backend logs to see the exact datetime payload the assistant is generating and passing to the tool. This will help us pinpoint whether the LLM is formatting the date incorrectly or if there's an issue with the tool's timezone settings.