Introducing Open API support for Data Service

I am happy to announce release of Data Service Open API endpoints which allow you to access your Data Service entities from an external application. The APIs allow same functionality as Data Service Studio activities and create, upload, delete, or retrieve data from any entity you have read and/or write permissions in Data Service.

You will need to register an external application in UiPath Automation Cloud, and grant any of the supported scopes to the external application:

  • DataService.Schema.Read
  • DataService.Data.Read
  • DataService.Data.Write

You still have full control on the data as the final set of permissions is combination of configured application scopes and the user’s permissions already configured in Data Service.

Learn more about the APIs and related functionality in our documentation.

We will love to hear your ideas, use cases, suggestions and questions around this!



1 Like

@ankit.saraf Is there a way to access this api with client credentials? I’m trying to get a token with the user scopes you defined above, and I registered an external app with those scopes, but when I use the client credentials grant type I get “unauthorized_client”

@Samantha_M - Sorry about my last answer, I didn’t read the details completely and ended up giving a wrong answer. I have deleted it to not confuse other users.

Client Credentials are only supported for “Application” scopes and as all Data Service scopes are “User” scopes, it is not possible to get client credentials for them. We need to keep Data Service scopes at “User” scope to ensure that none of the role/user permissions done in your tenant are bypassed.

Can you please share a little more about the scenario you are trying to achieve?

Hi Ankit, okay thanks for the info. We were hoping one of our other systems, outside of ui path, could access the data service via API so we could reuse the data we had there

Thanks for that info.

You can still do that by using Authorization Code mechanism -

You can request a refresh token as part of the authorization code flow by using the offline_acess scope and then subsequently use it to get access tokens.

CC: @zawad

Thanks for the info. We tried that but stopped when we saw this step: “A user must log in to Automation Cloud to authenticate the authorize request.“

We’re looking for more of a service to service authentication, without the need for user input?

@Samantha_M - The “authorization” will need to be one time call that will ensure that the subsequent calls will happen under the context of “the user” who authorizes it. One you get the refresh token, no user interaction in needed after that unless the refresh token expires.

Think of that first step as deciding which “user’s permissions” will be used to access Data Service from your external system.

CC: @Karan to track on our backlog

Okay I think I understand. Thank you so much for your help and explanation!!

You are welcome @Samantha_M, please do let us know if you run into any issues.

Just to add to this, what is the best way to store a password in Data Services?

If the password is going to be accessible to only a small set of users/robots, then you can enable field level security for that field and restrict it only to the users who should have access to it.

Storing password in Data Service is just like storing password in a database, you have to restrict who can access it.

@ankit.saraf : is there a way to use only one API for external users to expose Data service entity table records? I am looking for simplified solution here

As per documentation, we have to submit OAuth2 request for refresh token (expire after 60 days) and then get new value of API access token so that business stakeholders can continuously sustain the connection and perform business function without any human intervention. It seems two steps API request.
Is it correct understanding to expose data service entity table (as mentioned above) as API endpoint for external business users?

@Sonalk - Yes, your understanding is correct that today, there is one step to get/refresh the OAuth token and then second step to actually call the Data Service API.

We are working with Automation Cloud platform team to introduce a mechanism for generating “personal access token” (similar to this and this) which should available later this year that will make the token permanent (with expiry). This way the actual API calls will be a single step call.

HI Ankit. Any news on those improvement.

Currently Im having a issue connecting an app to the Data Service API.
I managed to generate the refresh token, but the app dont have support for rotating these tokens. With that, I need to somehow keep a permanet connection with UiPath API, any suggestion on how to do that?