Skip to Main Content
Nintex Ideas

đź‘‹ Use this site to provide feedback and ideas for all Nintex Products. See our post on Nintex Community "Welcome to Nintex Ideas" for more details on Nintex Ideas, how an idea is handled by our product teams and more!


If you have questions about Nintex Ideas, please contact ideas@nintex.com

If you require support, please visit Nintex Customer Central

If you have a sales inquiry, please contact sales@nintex.com

Status Open for voting
Categories Other
Created by Alexandre
Created on Feb 6, 2024

Align NAC API with NAC features

NAC is being constantly improved (which is great!), nevertheless the API is not following the upgrade pace and is not really up-to-date.


For example :

  • The form Access feature that enable to filter who can trigger a form is not available from the API when you call the List workflows EndPoint. So the List Workflows list all the workflows even if a user has no right to see them (maybe the solution would be to add an optional user filter to the call?)

  • When listing the tasks, the URL returned by the API when a task is completed is a URL that says the taks has been completed. On NAC you have the possibility to see the form that has been submited. That would be good to have, in the return of the API call, the URL of the submitted task form (and not only the message saying that the task has been submitted).

An up-to-date API would make it more usefull for developers to expand the capabilities of Nintex beyond its limits!



  • Attach files
  • Nico
    Reply
    |
    Feb 8, 2024

    Great ideas ! And very usefull.

    An important thing to add is to allow authentication to the API with the user's session.

    Currently, this is only possible with a personal access token or an app token. This limitation places huge restrictions on the use of the API.


    On simple exemple :

    if I want to develop an APP that displays the tasks of the current user. Each user must first create their personal access token in NAC, which gives them a 'Developer' role, and then configure this token in the APP. Not really usable in a production context.