Splunk Search

Eval error via REST API

naorbarlev
Engager

 

Hi, 


I'm receiving the following error message: 

Error in 'EvalCommand': Failed to parse the provided arguments. Usage: eval dest_key = expression.

I am tring to create the seach via REST API. Is there something special that i need to know about API calls?

Via the UI -  the search works.

Thanks!

Labels (1)
0 Karma

marnall
Motivator

Could you share the search? It could be that it is using characters that work fine in the UI search bar, but which get interpreted wrong when passed to the REST API.

naorbarlev
Engager

 

Yes, for example this seach:

 

search index=* | eval ip="8.8.8.8" | search ip | stats count by index | eval result=if(count>0, "IP found", "IP not found")
0 Karma

marnall
Motivator

I have a feeling that it's a problem with those double-quote characters in the eval command. Usually the search string has to be included as a parameter to the REST API request and enclosed with quotes (usually double quotes), so if your search string contains double-quotes, it may cut off at

| eval ip=

then Splunk will complain about a malformed eval expression. If your search string is indeed enclosed by double-quotes, then make sure that your double-quotes in the search are escaped:

search index=* | eval ip=\"8.8.8.8\" | search ip | stats count by index | eval result=if(count>0, \"IP found\", \"IP not found\")
0 Karma

naorbarlev
Engager


i had that feeing to, but it is still not working, more over , i tried the simplest query that does nor inclde any specail chars and it is still throwing the same error.

this also fails: 
index=* | eval bytes=10+20 | table id.orig_h, id.resp_h, bytes

 

 

0 Karma

marnall
Motivator

How are you sending the query? Via CURL? If so could you post the request you are using?

0 Karma

naorbarlev
Engager


No, it's via another platform. bacause of security reasons i can't share it, sorry.

Do you have any ideas why should it happen?

 

0 Karma

marnall
Motivator

I tried sending a sample query via API:

 

search index=* earliest=-20m | eval bytes=10+10 | head 10 | table _time bytes

 

And I got the same Eval error as you. When I URL-encode the search query:

search%20index%3D%2A%20earliest%3D-20m%20%7C%20eval%20bytes%3D10%2B10%20%7C%20head%2010%20%7C%20table%20_time%20bytes

 

it returns results. Could you try URL-encoding your search query?

0 Karma

naorbarlev
Engager


After encoding it does run. But there is no results 😪

I do get results for queries without eval and URL-encoding.

0 Karma

marnall
Motivator

You may have to fiddle with the search query so that you URL-encode only the problematic characters in the eval statements, but leave alone the literal values used in filtering.

0 Karma

naorbarlev
Engager


Can you plaese show me how to do it on my query?

index=* | eval bytes=10+20 | table id.orig_h, id.resp_h, bytes
Thanks!

0 Karma

marnall
Motivator

You can start the REST search query with index=* and then add the subsequent commands one-by-one to see where the results get filtered out or when the errors come up

0 Karma

naorbarlev
Engager

 

Its such a mystery! I think i tried everything already, each time the query has the eval command there is no results coming back.

0 Karma

marnall
Motivator

Do you get any results from the search in the API call? You could start the search simple, like index=yourindex  | head 5, and ensure there are 5 results returned. Then build it up step by step until you find the part of the SPL search which is not working.

0 Karma
Get Updates on the Splunk Community!

Data Management Digest – December 2025

Welcome to the December edition of Data Management Digest! As we continue our journey of data innovation, the ...

Index This | What is broken 80% of the time by February?

December 2025 Edition   Hayyy Splunk Education Enthusiasts and the Eternally Curious!    We’re back with this ...

Unlock Faster Time-to-Value on Edge and Ingest Processor with New SPL2 Pipeline ...

Hello Splunk Community,   We're thrilled to share an exciting update that will help you manage your data more ...