question Re: Unable to stop processor using API in Support Questions

Unable to stop processor using API

nifier — Wed, 10 Sep 2025 15:33:53 GMT

Hi,
We have a flow created with ListSFTP , we have it scheduled it once per day, but for some reason if files are not available at source, we would like to Stop it and execute Run Once and Start the Primary Processor again.
These step work fine from NiFi UI but when we try to use NiFi Api (/processors/{id}/run-status) to stop the Primary processor, the Processor wont stop, we are passing the latest Version Id and Client Id as well.
any suggestion on how to fix this ?

Re: Unable to stop processor using API

MattWho — Wed, 10 Sep 2025 17:12:28 GMT

@nifier Sharing the details of the rest-api calls you made that are not working along with the specific Apache NiFi version being used may be helpful in providing guidance here.

What response are you getting to your rest-ai calls?
What do you see in the nifi-user.log and/or nifi-app.log when you execute your rest-api calls?
How are you handling user authentication in your rest-api-calls (certificate, bearer token, etc)?

rest-api call:

https://<nifinode>:<nifiport>/nifi-api/processors/<Processor UUID>/run-status -X PUT -H 'Content-Type: application/json' --data-raw '{"revision":{"clientId":"<ID>","version":<version num>},"state":"<RUNNING, STOPPED, or RUN_ONCE>","disconnectedNodeAcknowledged":false}' --insecure

Above would also need a client auth piece.

What may be helpful to you is utilizing the developer tools in your web browser to capture the rest-api calls made as you perform the actions via the NiFi UI. Most developer tools give you the option to "copy as curl" the request that was made.

Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped.

Thank you,
Matt

Re: Unable to stop processor using API

nifier — Thu, 11 Sep 2025 07:37:52 GMT

@MattWho

We were able to resolve it there was a typo in our api call.

Thanks for your suggestion.