Hi @michaelnorup, about the trendline, if you havedata to create the trendline in the results of the loadjob , you could elaborate them. I cannot see tem because, after a timechart you don't have other fields, see, removing the timeachart, which fields you have, so you could modify your search. If you would help, please share your search in text mode (using the Insert/Edit Code Sample button), not as a screenshot, eventually with a masked part, to avoid to re-write all the search. Ciao. Giuseppe

@priyanshuraj400 - I'm assuming you are using the `rest.simpleRequest` method. In there, you can pass a parameter called timeout. For example rest.simpleRequest(apiPath, sessionKey=mySessionKey, method='GET', timeout=None)   I hope this helps!!!

Hi @Thulasinathan_M , good for you, see next time! let me know if I can help you more, or, please, accept one answer for the other people of Community. Ciao and happy splunking Giuseppe P.S.: Karma Points are appreciated

@ssharm223 did you ever get an answer to this? Guessing no? I'm having the same issue with accessing a csv lookup that I can access via the web UI, however attempting to access it via API gets me: Non-result: ERROR The lookup table 'asset_lookup-by_str' requires a .csv or KV store lookup definition.. However changing the search to "|inputlookup asset_lookup-by_str.csv" still gets me: Non-result: ERROR The lookup table 'asset_lookup-by_str.csv' requires a .csv or KV store lookup definition.. I suspect there is some combination of non-filesystem access and non-default csv locations that means we are SOL, but happy to be proven wrong by the brains trust!

It needs a longer explanation. I believe long time ago the things were as you tried to set them up - the events were distinguishable by sourcetypes. But since there is no actual need to treat them as separate sourcetypes (sourcetype defines how the data is processed - ingested and parsed) because the data is in the same format regardless of which particular EventLog channel it came from and having separate sourcetypes for each EventLog  channel would mean that you'd need to define settings for each new channel you ingest (and you can pull any of the channels you see in your EventLog!). So there was a shift in the approach to windows events (and it happened looooong time ago). And in order to accomodate all those forwarders installed long time ago and still working with old defaults (configured as you tried to set it up), there are transforms in TA_windows which "normalize" the sources and sourcetypes. This is from default/transforms.conf: ## Setting generic sourcetype and unique source [ta-windows-fix-classic-source] DEST_KEY = MetaData:Source REGEX = (?m)^LogName=(.+?)\s*$ FORMAT = source::WinEventLog:$1 [ta-windows-fix-xml-source] DEST_KEY = MetaData:Source REGEX = <Channel>(.+?)<\/Channel>.* FORMAT = source::XmlWinEventLog:$1 [ta-windows-fix-sourcetype] SOURCE_KEY = MetaData:Sourcetype DEST_KEY = MetaData:Sourcetype REGEX = sourcetype::([^:]*) FORMAT = sourcetype::$1 Even if you explicitly configure your inputs to provide source and sourcetype "old style" the transforms will get invoked during indexing an will overwrite the metadata fields to the "new style". So all windows EventLog-sourced events are of either WinEventLog sourcetype or XmlWinEvenLog one (depending on whether you ingest them as "classic" or XML).