### Answer When you configure a custom function with the PATCH HTTP method in Retell AI, the LLM determines which arguments to include in the request based on your parameter schema definition [(1) ]() [(2) ]() . The payload sent to your endpoint follows this structure for POST, PATCH, and PUT requests : - **header**: Contains

X-Retell-Signature

for request verification and

Content-Type: application/json

- **body**: Includes

name

(function name) ,

call

(call object with context) , and

args

(the arguments as a JSON object) However, there's an important configuration option called "Payload: args only" . When this is enabled, the JSON body contains only the function's arguments at the top level, not nested under

args

, and without the

name

and

call

wrapper . Key consideration for your use case: The LLM decides which parameters to include based on your JSON schema's

required

fields and the conversation context . If you're seeing all variables sent every time, this is likely because: 1. Your schema marks fields as

required

2. The LLM is interpreting the conversation to include all available parameters Recommended approach: To achieve true PATCH behavior where only modified fields are sent, consider: - Remove

required

constraints from fields that should be optional in your parameter schema - Use clear descriptions in your schema to guide the LLM on when to include each field - Implement server-side logic to handle the full payload by only applying non-null or explicitly changed values If you need to verify the request is from Retell, you can check the

X-Retell-Signature

header using the verification methods documented for Node.js and Python .

​ To learn more, see the sources I considered: [[1] Integrate any system with custom function](https://docs.retellai.com/build/single-multi-prompt/custom-function) [[2] Custom Function](https://docs.retellai.com/build/conversation-flow/custom-function) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer Thanks for the additional context. Given that your fields aren't marked as required and you've explicitly instructed the LLM to send only changed fields, this behavior suggests a potential limitation in how the LLM interprets partial updates. Here are additional troubleshooting steps: 1. Enable "Payload: args only" If you haven't already, enable the "Payload: args only" option for your custom function [(1) ]() . This simplifies the payload structure and may help with LLM interpretation. 2. Adjust LLM Temperature Consider using a lower temperature setting (0.1-0.3) for more deterministic behavior [(2) ]() . Higher temperatures can cause the LLM to be more creative in interpreting which fields to include . 3. Use Structured Output If available for your LLM model, enable Structured Output . This ensures the LLM strictly follows your defined schema and can improve reliability for function calls . Structured Output "eliminates missing or malformed function arguments" and "ensures all outputs match expected schemas" . 4. Backend Workaround Since the LLM behavior may not be fully controllable, implement server-side logic to: - Accept the full payload - Compare against your existing database record - Only apply fields that have actually changed values - Ignore fields with null, empty, or unchanged values 5. Schema Description Refinement In your JSON schema, add explicit descriptions for each field emphasizing they should only be included when explicitly mentioned:

json { "type": "object", "properties": { "field_name": { "type": "string", "description": "ONLY include if user explicitly provided or changed this value" } } }

[(1) ]() The documentation notes that with custom functions, "the LLM decides which parameters to include based on your JSON schema's required fields and the conversation context" . Unfortunately, even with clear prompting, LLM interpretation can vary. Your best path forward is likely the backend workaround combined with the structured output option if available for your model.

​ To learn more, see the sources I considered: [[1] Integrate any system with custom function](https://docs.retellai.com/build/single-multi-prompt/custom-function) [[2] Configure LLM Options](https://docs.retellai.com/build/llm-options) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

Appreciate the feedback! Feel free to ask me again with additional guidance or context.

### Answer Given that "Payload: args only" is already enabled, and you've explicitly instructed the LLM to send only changed fields, this appears to be a limitation in LLM behavior rather than a configuration issue. Since the documentation states that with custom functions "the LLM decides which parameters to include based on your JSON schema's required fields and the conversation context" [(1) ]() , and you've already: - Removed required constraints - Added explicit instructions in both the function description and agent prompt - Enabled "Payload: args only" Remaining options: 1. Verify your parameter schema structure - Ensure your JSON schema has

"type": "object"

at the top level [(1) ]() [(2) ]() . A common mistake is not adding this, which can cause validation issues . 2. Use

const

values strategically - In your parameter schema, you can use

"const"

for fields that should have fixed values or dynamic variables . This might help control which fields are included. 3. Backend-side filtering - Since the LLM ultimately decides what to include, implement server-side logic to: - Parse the incoming payload - Compare against your existing database record - Only apply fields that differ from current values 4. Consider Custom LLM integration - If you need more precise control over function calling behavior, you could explore integrating your own LLM via the LLM WebSocket [(3) ]() , which gives you complete control over how function calls are constructed and handled [(4) ]() [(5) ](

egrate-llm) . The documentation confirms that function results are capped at 15000 characters [(1) ]() [(2) ]() , so your response handling should account for this limit. Unfortunately, the available documentation doesn't provide a way to force the LLM to send only explicitly modified fields through configuration alone. The backend filtering approach is your most reliable solution.

​ To learn more, see the sources I considered: [[1] Integrate any system with custom function](https://docs.retellai.com/build/single-multi-prompt/custom-function) [[2] Custom Function](https://docs.retellai.com/build/conversation-flow/custom-function) [[3] Custom LLM Overview](https://docs.retellai.com/integrate-llm/overview) [[4] Integrate Function Calling](https://docs.retellai.com/integrate-llm/integrate-function-calling) [[5] Integrate LLM](https://docs.retellai.com/integrate-llm/integrate-llm) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

Appreciate the feedback! Feel free to ask me again with additional guidance or context.