Persist tokens across executions?

[joshualarkins]

I'm trying to use the REST API Mod Input to persist a timestamp parameter. Each time I make a request of the API I'm working with, it responds with the authoritative end timestamp that it is returning data for. Between subsequent executions, I need to store this value, so it can be provided with the next execution.

I've read most of the threads here on Answers, trying to find someone doing what I'm looking for. I can't seem to find anywhere there or in the Python code of the app that shows handling persistent tokens across REST input executions. Is this just unsupported? I have another API where I'd use this, but the checkpoint that API provides is a UUID that operates in the same way - each subsequent API call needs to provide the UUID sent in the previous response.

[baboonbones]

You'll get better support for this question at the App author's Slack #community channel : https://www.baboonbones.com/#support

[joshualarkins]

It seems like values stored to req_args["params"]["arbitrary_string"] within a custom responsehandler will turn into an entry in the inputs.conf, under the [rest://blah] stanza, with a key of arbitrary_string. I guess that works, but I was under the impression that Splunk Best Practices were to store that data in the $SPLUNK_HOME/var/lib/splunk/modinputs/ directory, usually via Splunk's API or the Splunk SDK. Are there any issues I should be aware of by using this method of storing checkpoints in the inputs.conf?

[masonmorales]

Here's an example: https://github.com/masonsmorales/python-checkpointer/blob/master/checkpoint.py

Instead of a timestamp, you'll need to parse out the UUID from the response and store it to disk, then reference it on the next run (similar logic).

[joshualarkins]

I'm familiar with the process of storing persistent checkpoints, but I'm trying to discover if this is supported within the framework of the tagged REST API app.