Hi guys I’m using make.com with only one module, db look up , to create a dynamic assistant. Close to 1 in 100 calls are rejected with assistant-request-returned-error. I’ve simplified the json output back to bare bones and it’s still getting rejected 1 in 100 approx. I can only think it’s the db latency however make.com is showing 4s execution each time Here is a sample call that failed. 019bdebf-c3d1-7bba-b866-f7e8237c0e8f Can you guys find the exact reason for the rejection? Nothing seems to be available for this in the API. If anyone has experienced anything like this, please let me know. Seven hours ago I sent an email to Support but I have not had a response so I thought I would see if anyone could help here

Thanks for sharing the details. To help narrow down the cause of the "assistant-request-returned-error," could you confirm if your webhook always returns an HTTP 200 status code and the exact required JSON structure (including a

results

array with matching

toolCallId

values) even in error scenarios? According to the documentation, missing these can intermittently trigger this error, even if execution time appears normal. If possible, please share a sample of the actual JSON response your webhook returns for both successful and failed calls (with sensitive data redacted). This will help identify any subtle formatting or status code issues that might be causing the rejections. [See troubleshooting guide for more details](https://docs.vapi.ai/tools/custom-tools-troubleshooting). Sources: - [Custom tools troubleshooting](https://docs.vapi.ai/tools/custom-tools-troubleshooting) - [Call ended reasons](https://docs.vapi.ai/calls/call-ended-reason)

@Vapi Support Bot yes always sending 200 response thats fixed imn output settings. Here is sample output that gets rejeceted 1 in 100 { "assistantId": "68e35bbe-8b54-4c2b-a80d-964353d49826", "variableValues": { "prompt": "you are a helpful assistant and you speak in short sentences", "toemail": "somvalidemail@acme.com", "fromemail": "anotheremail@acme.com", "greeting": "hello how are you. waht can i do", "alertnumber": "" } }

Thanks for sharing your sample output. According to the Vapi documentation, the webhook response must include a

results

array with objects containing a

toolCallId

and a

result

(or

error

) field, all as strings. Your sample output does not include this structure, which can cause intermittent "assistant-request-returned-error" issues—even if HTTP 200 is always returned ([see troubleshooting guide](https://docs.vapi.ai/tools/custom-tools-troubleshooting)). Example of required response format:

json
{
  "results": [
    {
      "toolCallId": "call_123",
      "result": "Your response as a single-line string"
    }
  ]
}

Clarifying question: Are you able to update your webhook to always return the above

results

array structure (with the correct

toolCallId

), even in error cases? Source: - [Custom tools troubleshooting](https://docs.vapi.ai/tools/custom-tools-troubleshooting)

sorry I should say Im trying to use transient assistants not dynamic assistants I think thats the correct terminology

Most of the time that assistant-request-returned-error from Vapi when calling Make.com means Vapi didn’t actually get a valid response back even though Make shows the scenario ran fine. It can happen if the webhook response arrives a bit too late or isn’t exactly the JSON structure Vapi expects, and since Vapi has a tight timeout window it just drops it and throws that error. Sometimes Make scenarios are slow in rare runs (DB lookups, cold starts) which makes the webhook return empty or invalid data to Vapi. Check the raw responses Make sends back for both success and failure, make sure the JSON always matches Vapi’s expected schema, and try returning a simple default if the lookup takes too long. Those intermittent cases are almost always about timing/format, not a specific visible API error code.

Thanks very much. Ive tried to rule out timing (since make.com always executes within 4 seconds) and I have stripped the output of make.com back to something very basic (see above) and it still fails 1 in 100 even thought its exactly the same output each time so that is really odd.

@John Walker Only just spotted this ... very interested in the results!

it was make.com introducing random delays and even though every scenario executed within four seconds according to the logs there there were clearly other delays. So it wasn't my Microsoft SQL calls it was just make.com. I was on the core plan and they wanted more money to prioritise transactions. So I spent the last two days writing some simple code to do the same job. It's been tested thoroughly and it's very robust and now calls are being answered within one second instead of six seconds. There's been a lot of good learning here including learning that the detailed error messages are sent back to the web hook. I've had Cursor build a hole of really useful debugging code for me that reads in vapi, make and twilio logs and correlates them. But now my phone calls are answered really fast, which is a huge benefit of all this. I don't have to pay Make.com more money for prioritising my requests which might not even work anyway and then they might want more money for the enterprise plan. And my phone calls still wouldn't be answered quickly. I can't believe how fast it is now. Typically one ring or less.

@John Walker thanks for the detail, and I'm happy you got it solved (even if the solution was to not use Make for that specific task!). Just out of curiosity ... was it essential to use MS SQL? You might have had a much faster response if you were using the native Make Data Store, as that's simply a JSON structure held in memory. You could also cache that in Make from your MS SQL database. Though that would probably all be overkill in this case ... I'm feeling that you've found the right solution for this specific issue!

Hi John, sorry for the delay. Could you please provide a few more affected Call IDs? Thanks!

yeah @DeeGee it was good to get it solved and it was unfortuante that the total execution time reported in make.com did not seem to be accurate for this scenario that had to be excecuted quickly because that threw me for a very long time and I was looking in the wrong place. I also had a lot of trouble editing the scenario which was another frustration. I think perhaps caching in make would have solved at least that part of it.. Now my code means calls are answered in 1 second which is just fantastic so that alone justified rewriting this particular scenario in my own code. Now I have some memory caching in my code and two redundant databases in different regions so it will kit the cache first most of the time and then try each database in turn. Next I will duplicate the code and put it behind a proxy or load balancer for app /webhook redunancy and then it will be super stable. I will keep all my other stuff in make.com for now since that is not so critical. @Shaunak since i realised vapi was sending more error details back to my webhook I was able to prove it was a 7.5 sec timeout issue in every case even though Make.com said it was executing in 4 seconds. So that was a huge breakthrough.

You’re right, for assistant-request webhooks, Vapi has a ~7.5s timeout. If the response comes in after that window, the request is rejected, even if [Make.com](http://Make.com) reports a shorter execution time.

I suspect that Make is reporting the execution time once the Make scenario has started executing. If there's a delay in starting the scenario (which can happen at the top of the hour when external systems often schedule their activity), that can impact the overall end-to-end response time. We don't have any "high priority" queue mechanism at present - but that's something we're looking into for the future.

it was us2. There was no ryme or reason to it.. it wasnt happening when there had been no activity or top of the hour or anything. here are some timestamps of a failed one. There often seems to be multiple entires for these failed ones perahps beacuse vapi is sending errors back to the webhook .. thats what I can see in the webhook history anyway. Jan 22, 2026, 5:07:02 PM Instant Success 4 seconds 3 3 12.6 KB Jan 22, 2026, 5:07:02 PM Instant Success 4 seconds 3 3 12.9 KB Jan 22, 2026, 5:06:48 PM Instant Success 4 seconds 3 3 12.5 KB

@John Walker can you confirm your time zone?

AEST

@John Walker Could you DM me the links to the execution history for that scenario in Make?