Skip to content

[BUG]: API request body is sent blank if there are ${variables} within request body JSON. Also some suggestions. #4187

@Jawzper

Description

@Jawzper

How are you running AnythingLLM?

AnythingLLM desktop app

What happened?

Issue

I just started playing around with agents recently, and I have been banging my head against the wall all day trying to figure out the cause of "status 400"/"unknown error" results I've been getting trying to use an agent to perform API calls. I have assumed user error up until now because I had never made an API call in my life until today, but it seems like something more might be going on here.

The AnythingLLM agent output:

Making POST request to external API...
Sending body to http://localhost:1234/v1/chat/completions: No body
Request failed with status 400
Flow failed: Unknown error

On the LM studio backend I get:

2025-07-22 20:58:54 [DEBUG]
 Received request: POST to /v1/chat/completions with body  {}
2025-07-22 20:58:54 [ERROR]
 'messages' field is required

Before and after that the agent appears to work through all the variables and then finally spits out a "sorry your tool call failed" type of message.

This is all with "content": "${planner-instructions}\n${inputinstructions}" as part of my request body, which is all validated JSON in the correct format. What I discovered is that if I remove all the ${variables} that are in the JSON of my API call, the agent does its thing with no problems, the POST succeeds, the correct model loads, it's all good.

So apparently the variables are the cause of my problem. Based on the documentation I was under the impression this should be fine so I am marking it as a bug, but maybe this is just a documentation issue: https://docs.anythingllm.com/agent-flows/blocks/api-call

So I must ask, is this expected behavior? What is the correct format for variables in the API POST json? Am I supposed to escape these brackets?


Enhancement ideas

Tangentially, this has all brought forth some suggestions that would have made my life much easier today:

  • Add a clear breakdown of the exact steps an Agent should be expected to take in trying to fulfill a request to the documentation. I feel this is important for end-user troubleshooting, I spent far too long today trying to guess whether I had a syntax error or an uncooperative agent that just likes to send blank API calls and go in loops.
  • Allow user to AT LEAST view the agent's system prompt easily. Again, this is useful information for troubleshooting. Given that the agent is capable of connecting to the internet and interacting with files, I also want to be able to see for myself that there are no user-hostile instructions or phoning home. I don't like the idea of LLMs running unknown instructions on my computer, so this would have been a deal breaker for me if I were not able to find the prompt buried in the git code.
  • Better yet, give the user complete control over the agent system prompt. Setting global defaults for per-workspace configurations would enable tailored use cases and also allow to attempt some measures against unwanted behavior (eg. don't f*ck with my variables, don't run the tool call multiple times, don't use reasoning etc, don't waste tokens randomly telling me about "What is AnythingLLM?").
  • Allow the user to choose the model called by LLM Instruction blocks. If this were an option I would still be blissfully enjoying never having to mess with JSON for API calls, because my problems would all be solved...
  • Logic operation flow blocks (like IF/OR/ELSE/GOTO/CONCATENATE and other operations) would unlock many possibilities if built in.

Are there known steps to reproduce?

Create an agent flow with one or more variables defined.
Add and configure an API POST request block to request completion by LM studio.
Include the defined variable in the content of the request body.
Ask the agent to call the tool flow.

Expected outcome: Error 400, flow failed, AI apologies

Metadata

Metadata

Assignees

Labels

investigatingCore team or maintainer will or is currently looking into this issuepossible bugBug was reported but is not confirmed or is unable to be replicated.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions