Skip to main content
Purpose: prepare the agent with customer context before the call starts. Key points:
  • They run before dialling, so they never interact with the customer.
  • They inject information dynamically into the agent’s system prompt.
  • They can call APIs.
  • They are used for gathering data and personalising the call.
  • They can even decide whether a call should be triggered or skipped. Example: a call meant to remind a customer to finish their KYC can be skipped if the customer has already done it.
Common uses: fetch customer details, identify interested products, check the lead stage, fetch previous interactions, build a personalised greeting, and stop unnecessary calls from being triggered. Example: getLeadDetails() returns the customer profile, used to personalise the opening conversation.
Note: If a Pre-Call function fails or raises an error, that call won’t be triggered to the customer. It will be saved with the hangup reason PRE_CALL_FN_FAILED.

Basic vs Advanced Pre-Call

Use a Basic Pre-Call function when all the data fetched by an API is to be injected into the prompt as raw data. Use an Advanced Pre-Call function when the data needs further refinement before injection, or when some custom logic must be applied first — like turning an ISO date-time slot into a human-readable format. There are two types of Advanced Pre-Call functions:
  • Advanced A: has access to the whole call data — the call type (inbound, outbound, scheduled, test), the customer’s phone number, the call metadata, and so on. It can fetch data using APIs or modify the metadata. To use this type, turn the “Update Call Data” toggle ON.
  • Advanced B: has access to only the system prompt and the metadata. It can modify or dynamically write into the system prompt — based on the metadata, or on data it fetches about the customer. It must always return the final prompt.
How they work together: the Advanced A function always runs first among all pre-call functions (and its syntax is different from Advanced B). It is generally used to fetch and set the customer metadata. After that, Advanced B functions can use that metadata. Advanced B can also fetch data using APIs, but it is best not to modify the metadata in Advanced B, because that would affect how other Advanced B functions behave. So Advanced B should only consume the fetched data and may insert it into the metadata — but should never modify existing metadata unless explicitly needed. For a simple use case, just use a single Advanced B function: fetch the data and inject it into the prompt. Don’t create more than one pre-call function.
Pro Tips: Keep each function small and focused on a single job. Write clear error messages to help with debugging — use logger.warning, and never use logger.error. Only log important events, for monitoring and debugging. Test edge cases and error conditions.