The short answer
Booking during a call is a function, not a webhook. You register an HTTPS endpoint with a JSON Schema describing its arguments; when the caller asks about availability the agent calls it, waits, and speaks the answer. Because someone is listening, the timeout is bounded to between 1 and 30 seconds, and the agent fills the silence with a spoken waiting line.
Last reviewed
Default spoken waiting message by function category
| What the caller hears while your endpoint runs | |
|---|---|
| lookup | “Let me look that up for you.” |
| search | “Searching now, just a moment.” |
| action | “On it, give me a second.” |
| payment | “Processing your payment, one moment.” |
| other | “One moment please.” |
What does a booking function look like?
A name, a description, a parameter schema, a URL and a timeout. The name is the identifier the agent uses, must be snake_case, at most 64 characters, and unique within your account — `check_availability` is the canonical example. The description is not decoration: it is what the model reads to decide whether this is the moment to call the function, so it should be specific about inputs and outputs.
Parameters are a JSON Schema object. For availability that is typically a required date plus an optional service type constrained to an enum, which keeps the agent from inventing a service you do not offer. The schema is validated when you save the function, not when the agent first tries to use it.
What does the caller hear while my endpoint runs?
Every function has a category, and the category chooses a default spoken line the agent plays when the call takes more than a moment. The table above lists them. You can override the line per function when the default does not fit your script.
If your endpoint exceeds the timeout the agent says "Sorry, I’m having trouble accessing that right now." — again overridable — and a `function.timeout` webhook event fires so the failure shows up in your monitoring rather than only in a transcript.
How is my endpoint authenticated?
Each function gets its own webhook secret. It is returned once when you create the function and once more if you rotate it; after that the dashboard shows only a six-character prefix, and the value itself is held encrypted in the credentials vault.
Requests to your endpoint are HMAC-signed with that secret. Verify the signature before acting on a booking request — this endpoint changes state in your calendar, which makes it a more attractive target than a read-only lookup.
What are the setup steps?
Build an HTTPS endpoint that accepts the arguments in your schema and answers well inside your chosen timeout. Register the function in Rexa with its name, description, schema, URL and timeout, and pick the category whose waiting message suits it. Store the secret it returns — you will not see it again. Then attach the function to the agent that should be allowed to call it.
A call can carry twenty functions in total, counting both the ones stored on your account and any passed inline at dispatch. A name that collides between the two is rejected rather than silently resolved.
Frequently asked questions
- Does Rexa integrate with Cal.com or Google Calendar?
- Not natively. There is no connector, no OAuth flow and no calendar picker for either. Both have APIs, so an endpoint of yours can sit between Rexa and the calendar — but that endpoint is something you build, and Rexa knows nothing about the calendar behind it.
- What happens if my scheduler is slow?
- The agent plays the waiting line for your function’s category so the caller is not left in silence. If the endpoint exceeds the timeout you set, up to a 30 second maximum, the agent apologises with a configurable message and a function.timeout event fires for your monitoring.
- How many functions can one call use?
- Twenty, counting stored functions and any passed inline at dispatch together. If a stored function and an inline one share a name the request is rejected rather than one silently winning, because an ambiguous tool name is worse than a clear error.
Scope, limitations, and sources
There is no Cal.com, Google Calendar, Outlook or Calendly connector — no OAuth, no calendar picker, no free/busy sync. Rexa calls an endpoint you write, and translating that call into a real booking in a real calendar is your endpoint’s job. The endpoint must be reachable from the public internet over HTTPS and must answer within 30 seconds at the absolute outside, which caps how much work it can do while a human waits; holding a tentative slot and confirming it are two things you may need to design around that limit. Twenty functions per call is a hard combined cap. And if you only need to record a booking after the call rather than make one during it, this is the wrong mechanism — use webhooks.
Sources
- Mid-call function definitions, parameter schemas, timeout bounds and spoken waiting messages. rexa.ai (accessed )
- Outbound webhook event catalog, signature headers and the delivery retry schedule. rexa.ai (accessed )
Spotted something out of date or wrong? Tell us on the contact page and we will correct it and update the review date.