Just spent the last three hours spelunking through API logs because the new Kling update silently changed the function-calling JSON schema. My custom script that pulled cost estimates and formatted them for our internal billing dashboard is now throwing `KeyError: 'parameters'` like it's going out of style. 🪦
Looks like they've moved from the older OpenAI-esque format to something closer to the Gemini style. The breaking change isn't in the main docs yet (of course). Here's what my working call looked like before:
```python
tool_call = {
"type": "function",
"function": {
"name": "get_cost_breakdown",
"parameters": { # <-- This key is now the issue
"service": "aws_ec2",
"timeframe": "monthly"
}
}
}
```
Now, the `"function"` object seems to expect `"args"` instead of `"parameters"`. Has anyone else reverse-engineered the new spec? Specifically:
* Is it just a straight rename from `parameters` to `args`?
* Did the structure of the value change (e.g., now requires a JSON string)?
* Any other gotchas in the response parsing?
I'll patch my own scripts once I figure it out and share the diff. This is why we can't have nice, automated things. The cloud giveth, and the API update taketh away.
- elle
- elle
It's not a straight rename to "args" in the function object itself. The new schema nests the parameters under a "tool_calls" array in the response message. The direct "function" key you're handling in the request likely now expects an "arguments" key containing a JSON string, not an "args" object.
I've seen this cause issues in our APM ingestion. The parsing step needs to change from accessing `response['function']['parameters']` to something like `response['tool_calls'][0]['function']['arguments']`, and then you must `json.loads()` that string value.
null
That parsing logic works for the *response*, but it's only half the story. The original post is about a *request* that's failing with a KeyError. Your fix addresses the downstream handling of what Kling sends back, not the format they now expect on the incoming call.
The silent schema change likely applies to both sides of the handshake. If they've moved to an "arguments" key expecting a JSON string in the request, then the initial function call object in the payload is fundamentally wrong, not just the parsing step.
Question everything
You're absolutely right to focus on the request side. The KeyError on 'parameters' is happening because the script is still building the old payload structure.
If Kling now expects 'arguments' with a JSON string, the error might not even be from their validation - it could be your own code failing when it tries to read back a 'parameters' key that it just sent. Have you checked the actual HTTP error from the API call itself? Sometimes that message points directly to the malformed field.
You're jumping ahead. The error's in your request payload, not the response parsing. If Kling's API changed, your script is sending invalid JSON and their server is rejecting it or returning a differently shaped error.
Check the actual HTTP status and error body from the API call. That'll tell you if it's a `400` with a validation message about the missing `arguments` field. My bet is the new schema requires `"arguments": "{"service": "aws_ec2"}"` as a JSON string, not an `args` object.
Patch the request first. Then worry about the response changes user443 mentioned.
Right, check the actual error response. If it's a 400, that confirms the request format is the issue. But if you're getting a KeyError from your *own* code, not the API, then the script is still trying to read from the old structure it built.
In that case, patching the request object's structure is step one. Change `"parameters": {...}` to `"arguments": json.dumps({...})`.
Then deal with the response parsing change separately.
âcp