https://retellai.com/?utm_source=discord&utm_medium=seo logo
hello guys I am running into any issue with Retell
# ❓・ai-evy-support
s
@AI Evy hello guys I am running into any issue with Retell. It is letting me book via the voice agent but for some reason no sooner than 10am when my hours of operation are 8:30 - 4:00. I have tried everything recommended
a
Thanks for tagging me @SandyMan. I'll look through relevant sources and get back to you shortly.
​ To learn more, see the sources I considered: [[1] Dynamic Variables](https://docs.retellai.com/build/dynamic-variables) [[2] Discord message from @jordansachi on 2025-10-15](https://discord.com/channels/1186424376300679209/1186462578310910112/1428116455597146247) [[3] Discord message from @dunbar_68134_54083 on 2026-01-24](https://discord.com/channels/1186424376300679209/1186462578310910112/1464721085064020028) ​
### Answer This sounds like a timezone or hours configuration issue. Here are a few things to check: 1. Verify your timezone settings Retell AI uses
America/Los_Angeles
as the default timezone. [(1) ]() If your business operates in a different timezone, you need to explicitly set it. You can use dynamic variables like
{{current_time_[timezone]}}
or
{{current_hour_[timezone]}}
to reference the correct timezone. For example, if you're in Eastern time, use
{{current_time_America/New_York}}
. 2. Include operating hours in your prompt or knowledge base You can include your opening hours (8:30 AM - 4:00 PM) within your prompt and/or knowledge base, and combine it with the
{{current_time}}
variable so the agent knows whether it's within operating hours. [(2) ]() 3. Consider using Conversation Flow for time-based logic If you need conditional logic based on time (like only booking during certain hours) , Conversation Flow provides the structured pathways needed for this. [(3) ]() Single prompt cannot dynamically handle scheduling logic as effectively. What to check specifically: - Confirm what timezone your booking system/calendar uses vs. what Retell is interpreting - Ensure your prompt explicitly states "8:30 AM to 4:00 PM" with the correct timezone - Check if your external booking tool (Cal.com, etc.) has its own timezone or availability restrictions Could you share more details about how you've configured your hours—is it in the prompt, a knowledge base, or through an external booking integration?
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
s
so in retell for the check availability and book appointmnet function i have Australia/Brisbane, for cal.com i have Australia/Brisbane and for google calendar i have the same
so in retell for the check availability and book appointmnet function i have Australia/Brisbane, for cal.com i have Australia/Brisbane and for google calendar i have the same @ai evy
so in retell for the check availability and book appointmnet function i have Australia/Brisbane, for cal.com i have Australia/Brisbane and for google calendar i have the same @AI Evy
a
Thanks for the follow-up, @SandyMan. I'll get back to you soon.
### Answer Since you have
Australia/Brisbane
set consistently across Retell, Cal.com, and Google Calendar, the issue is likely that your agent's prompt doesn't know the current time in your timezone. [(1) ]() Even with the function timezone set correctly, the LLM itself needs to be explicitly told the current time so it can reason about what slots are valid. [(2) ]() Add this dynamic variable to your prompt: Use
{{current_time_Australia/Brisbane}}
in your agent's prompt so it knows the actual current time in Brisbane. [(1) ]() For example, include something like:
Copy code
The current time is {{current_time_Australia/Brisbane}}. 
Our operating hours are 8:30 AM to 4:00 PM Australia/Brisbane time.
Only offer appointment times within these hours.
Why this matters: The agent doesn't automatically know the current time or timezone context without you explicitly providing it through dynamic variables. [(2) ]() Without this, the LLM may default to a different timezone (like
America/Los_Angeles
) when reasoning about availability. [(1) ]() Also verify in your prompt: Include explicit timezone conversion instructions so the agent checks availability in the correct timezone before making requests. [(2) ]() Try adding that dynamic variable and updating your prompt with explicit operating hours, then test again. Let me know if the issue persists!
​ To learn more, see the sources I considered: [[1] Dynamic Variables](https://docs.retellai.com/build/dynamic-variables) [[2] Timezone mismatch during outbound calls despite correct profile & Cal.com event settings](https://community.retellai.com/t/timezone-mismatch-during-outbound-calls-despite-correct-profile-cal-com-event-settings/783) ​
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
s
@AI Evy didnt work
a
Thanks for the follow-up, @SandyMan. I'll get back to you soon.
4. Debug the function call Review the call logs to see what parameters are actually being sent to Cal.com when booking. The logs should show the exact request being made. [(1) ](

▾

) Questions to help troubleshoot further: - Are you using Single/Multi Prompt or Conversation Flow? - When you test booking directly in Cal.com (not through Retell) , can you book at 8:30 AM? - What does the call transcript show when someone tries to book before 10 AM?
### Answer Sorry to hear that didn't resolve it. Since the timezone settings and dynamic variables haven't fixed the 10am minimum booking issue, here are some additional things to investigate: 1. Check your Cal.com event availability settings directly The issue may be in Cal.com's availability configuration rather than Retell. Verify that your Cal.com event type has availability starting at 8:30 AM (not 10 AM) in the event settings themselves. [(1) ](

▾

) 2. Use Conversation Flow with equation-based transitions For time-based booking logic, Conversation Flow provides more precise control. You can use equation-based transitions to check if the requested time falls within your operating hours before calling the booking function. [(2) ]() [(3) ]() 3. Verify the dynamic variable is actually being substituted Check your call logs to confirm
{{current_time_Australia/Brisbane}}
is resolving correctly. If a dynamic variable has no assigned value, it remains in its raw form with curly braces intact. [(4) ]() To check if a variable is set in Conversation Flow, you can use:
Copy code
Equation: {{current_time_Australia/Brisbane}} exists
Result: True if variable is set
​ To learn more, see the sources I considered: [[1] Part 1: BuildYour First Retell Voice Al Agent That Sells Cars](

https://www.youtube.com/watch?v=p0DusrDjfjA▾

) [[2] Platform Changelogs | Retell AI](https://www.retellai.com/changelog) [[3] Retell AI’s Advanced Conversation Flow | Retell AI](https://www.retellai.com/blog/unlocking-complex-interactions-with-retell-ais-conversation-flow) [[4] Dynamic Variables](https://docs.retellai.com/build/dynamic-variables) ​
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
s
@AI Evy for 1. i have thes hours set for ical: Working Hours - Nellies Hairdresser Working Hours - Nellies Hairdresser Mon - Tue, 8:30 AM - 4:00 PM Wed - Thu, 8:30 AM - 8:00 PM Fri, 8:00 AM - 4:00 PM Sat, 6:30 AM - 1:00 PM Set as default Save Sunday Monday 8:30am - 4:00pm Tuesday 8:30am - 4:00pm Wednesday 8:30am - 8:00pm Thursday 8:30am - 8:00pm Friday 8:00am - 4:00pm Saturday 6:30am - 1:00pm Timezone Australia/Brisbane 2. i will try that if this doesnt work. 3. this is the call log: 2026-02-18 06:52:23.256 call_71a797b29978432d616d5edf50f info: Starting call: call_71a797b29978432d616d5edf50f 2026-02-18 06:52:41.703 call_71a797b29978432d616d5edf50f info: E2E latency for this turn: 1408 2026-02-18 06:52:42.142 call_71a797b29978432d616d5edf50f info: Calling tool: check_availability_cal Arguments: {"start_time":"2026-02-19T08:30:00","end_time":"2026-02-19T09:30:00","timezone":"Australia/Brisbane","execution_message":"Checking availability for tomorrow at 8:30 AM with Alex."} 2026-02-18 06:52:43.099 call_71a797b29978432d616d5edf50f info: Received result for tool: dbba4fc1284f47e6 check_availability_cal Result: {"availability_for_selected_time":"No available slots for specified time range, but there are available slots on time range that's nearby.","availability_nearby":[{"date":"Wednesday, 2026 February 2/18/2026 Australian Eastern Standard Time","availability_range":["From 5:00 PM to 7:00 PM"]},{"date":"Thursday, 2026 February 2/19/2026 Australian Eastern Standard Time","availability_range":["From 11:00 AM to 8:00 PM"]},{"date":"Friday, 2026 February 2/20/2026 Australian Eastern Standard Time","availability_range":["From 8:00 AM to 9:00 AM"]}]} 2026-02-18 06:52:56.949 call_71a797b29978432d616d5edf50f info: Ending call: call_71a797b29978432d616d5edf50f 4. ?
a
Thanks for the follow-up, @SandyMan. I'll get back to you soon.
### Answer Your call log reveals the issue. Look at the result from Cal.com: Thursday 2/19/2026 shows availability "From 11:00 AM to 8:00 PM" — not starting at 8:30 AM as you configured. This means Cal.com itself is returning limited availability, not Retell. The Retell function is correctly requesting 8:30 AM (
"start_time":"2026-02-19T08:30:00"
) with the correct timezone (
"timezone":"Australia/Brisbane"
) , but Cal.com is responding that no slots are available until 11:00 AM. [(1) ]() Things to check in Cal.com: 1. Existing bookings — Do you have appointments already booked from 8:30-11:00 AM on Thursday? 2. Buffer times — Check if you have buffer times configured in Cal.com that are blocking early morning slots 3. Team member availability — If this is a team event type, verify the specific team member (Alex?) has their personal availability set to start at 8:30 AM, not just the event type 4. Multiple calendars — If you have multiple calendars connected, one might be blocking those morning hours The timezones in Cal.com and Retell must match for the booking features to work properly, which you've done correctly. [(2) ]() However, the issue appears to be on the Cal.com side since the API response shows restricted availability despite your working hours configuration. Try checking availability directly in Cal.com's booking page (not through Retell) for tomorrow at 8:30 AM to confirm whether the slots appear there.
​ To learn more, see the sources I considered: [[1] Timezone mismatch during outbound calls despite correct profile & Cal.com event settings](https://community.retellai.com/t/timezone-mismatch-during-outbound-calls-despite-correct-profile-cal-com-event-settings/783) [[2] CAL Issues And Questions](https://discord.com/channels/1186424376300679209/1348768358031687771) ​
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
a
Thanks for the follow-up, @SandyMan. I'll get back to you soon.
### Answer Based on your call logs, Retell is sending the correct request (
start_time: 2026-02-19T08:30:00
with
timezone: Australia/Brisbane
) , but Cal.com is returning availability starting at 11:00 AM. [(1) ]() Since the Retell configuration appears correct, this is likely a Cal.com-side issue. However, here are a few more things to try: 1. Add
{{current_time}}
before triggering calendar functions
Include the current time in your prompt before both the availability check and booking functions. This helps the LLM know what date/time it's checking for and avoids sending requests for times in the past. [(2) ]() 2. Verify you're using double curly braces Ensure all dynamic variables use
{{variable}}
format, not single braces
{variable}
. [(3) ]() 3. Check Cal.com directly - Log into Cal.com and try to book an appointment for tomorrow at 8:30 AM through their booking page (not through Retell) - Check if there are any existing bookings, buffer times, or minimum notice settings blocking early slots - Verify the specific team member's individual availability (not just the event type) - Look for any "minimum booking notice" settings that might be pushing availability later 4. Share a call ID If you'd like the Retell team to investigate further, sharing the full call ID in the Discord channel can help them look at the exact request/response flow. The issue appears to be that Cal.com is not returning the 8:30 AM slots despite your working hours configuration—Retell is correctly passing your timezone and requested time.
​ To learn more, see the sources I considered: [[1] Timezone mismatch during outbound calls despite correct profile & Cal.com event settings](https://community.retellai.com/t/timezone-mismatch-during-outbound-calls-despite-correct-profile-cal-com-event-settings/783) [[2] Urgent: Cal.com Booked on different day - Potential Service Disruption with multiple issue.](https://discord.com/channels/1186424376300679209/1423174290458808381) [[3] Issue with Global Variables Not Passing in Query Parameters for Custom Function Tool](https://community.retellai.com/t/issue-with-global-variables-not-passing-in-query-parameters-for-custom-function-tool/773) ​
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
g
@AI Evy Can the agent-level webhook receive a response from that same webhook or is it only for sending events and not receiving anything.
a
Thanks for the follow-up, @Goopa Snoops. I'll get back to you soon.
### Answer Agent-level webhooks are **one-way only**—they send call event notifications to your endpoint but do not receive responses that affect the call. [(1) ]() The webhook `POST`s event payloads (like
call_started
,
call_ended
,
call_analyzed
) to your URL, and Retell expects a successful status code (2xx) with no body in return. If you need to receive data and influence the call (like setting dynamic variables or overriding the agent) , you should use the Inbound Webhook instead. [(2) ]() The inbound webhook is triggered when an inbound call is received, and your response can include fields like
override_agent_id
,
dynamic_variables
,
metadata
, and
agent_override
to customize that specific call. Summary: - **Agent-level webhook**: One-way, sends events out, no response processing - **Inbound webhook**: Two-way, receives call notification and can return data to influence the call
​ To learn more, see the sources I considered: [[1] Webhook Overview](https://docs.retellai.com/features/webhook-overview) [[2] Inbound webhook](https://docs.retellai.com/features/inbound-call-webhook) ​
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.