Best Practice for Managing API Configuration in a Custom UiPath Library

Help Studio
, ,
1

Hi everyone,

I’m using a custom UiPath library to centralize reusable activities, mainly for API calls. In consuming processes, I only pass the service name, and the library handles resolving the endpoint, body, and executing the call.

I’m trying to decide the best way for the library to manage its own configuration data (endpoints, request bodies, etc.):

  • Internal text files (embedded in the library)
    • :white_check_mark: Fast and simple access
    • :cross_mark: Requires republishing the library whenever data changes
  • External config file
    • :white_check_mark: Easier to maintain and update without redeploying code
    • :cross_mark: Risk of runtime failures if the file isn’t accessible
    • :cross_mark: Versioning can be tricky if different consumers rely on different API versions

Based on your experience, which approach would you recommend? Or is there a better pattern I should consider?

Thanks in advance!

2

Hi @alfred.couvreur.ext

This is a great question. I do things slightly differently with my team, but it still follows best practice and it’s been a very successful implementation so far.

  1. I actually prefer converting the config to a JSON String. The reason is because this way, there is no file that can be altered or moved/deleted etc.
  2. Store this JSON String as an Asset inside Orchestrator. By doing this, you can reference it at any point in your code as a global variable easily, and also because it can be changed at any point without having to redeploy your code. Also, by storing it as an asset, it’s easy to migrate across environments/tenants. And the character limit for a Text Asset is 1 million characters - so you should be good.
  3. This also centralizes and secures the data all together. And a HUGE advantage is that it can be used across multiple processes if necessary (or in your case, libraries). It would also mean that your versioning is handled via Orchestrator, rather than that Text file.

That’s my story, give it a try and let me know if it works for you :slight_smile:

3

Thanks for your quick reply @JarrydScott, that’s an interesting approach.
My main concern with this solution is around versioning the data. How would you manage different versions of the JSON being consumed by the library across multiple processes? Some newer processes may require updated data, such as a newer API endpoint or request body, while older ones still rely on previous versions. Managing several versions of the same JSON as Orchestrator Assets feels like it could quickly become complex and hard to maintain.

4

In this case you have three options:

  1. You can maintain different versions of the API JSON String. Version 1 and 2 let’s say, BUT you need to label them strictly. It wouldn’t become complex or difficult to maintain because your naming conventions would assist you. This also avoids breaking existing processes when changes are introduced for newer ones.
  2. A more “flexible” approach would be to maintain one Asset JSON String, but label the API’s config inside the JSON according to their version. For example:
    {
    “v1”: {
    “ServiceA”: { “endpoint”: “…” }
    },
    “v2”: {
    “ServiceA”: { “endpoint”: “…” }
    }
    }
    and then when you call it, the expression will look something like this: config(version)(serviceName)("endpoint") - This approach might become more complex to maintain over time…
  3. Lastly, and this is what I have done in my recent project, is just create an asset for each API with it’s necessary data. Easy to maintain and easy to reference (but please label strictly). I only had 10 APIs, so it might have been easier than your process/library, but it is SUPER easy to manage/maintain. Only issue here is that it becomes fragmented. Worth exploring though.
5

I would like to challenge the structure of your library.

Do I understand correctly that the library handles multiple different services/applications and their APIs, and you are trying to pass in the service/application and what you want it to do?

If so I strongly disagree with this approach, you are putting way too much in a huge library and its bad practice.
You should not managing this by any config.

Make a library per service / application and forget the config file.

6

I really like this approach overall, especially because it makes the data easy to access, modify, and extend without redeploying anything. My only remaining concern is around long‑term governance: since Orchestrator doesn’t provide visibility into asset usage, there’s no straightforward way to know whether some parts of the JSON are still being used by any consuming process or library. Over time, this could lead to unused or obsolete data accumulating inside the asset.

7

Thanks for the feedback. I think there may be a small misunderstanding about the scope of my library.

The library does not manage multiple unrelated services or applications. It represents one backend platform API exposing several related business operations (e.g. CreatePerson, CreateCar, ModifyMaritalStatus, etc.) with the same semantics and data models, but deployed across different sub‑applications of the same company.

Conceptually, it’s similar to working with DEV / TEST / PROD tenants:

  • Same endpoints and operations
  • Same request/response structure
  • Only the base URL (and sometimes minor environment-specific details) changes

In consuming processes, I simply pass the target endpoint (or tenant) and the business data (name, age, etc.), while the library encapsulates the API logic itself. The goal is to avoid duplicating identical activities across multiple libraries when the API contract is effectively the same.

If these sub‑applications were to diverge functionally over time, I’d agree that separate libraries would make sense. But as long as they remain equivalent deployments of the same service, a single focused library feels appropriate.

8

Very good point. Orchestrator does not maintain version control over Assets itself. In your case I would suggest handling it yourself externally to Orchestrator:

  1. You can make use of DevOps version control like GIT or Azure to assist you in your maintenance and version control of this registry which I would strongly recommend. It would also contain pipelines with the project itself which makes it easier to keep up to date. And Azure DevOps can integrate directly with Orchestrator - so you can explore this.
  2. You can either create and maintain a registry yourself in a necessary shared space that strictly get’s governed by you or the business (not ideal but for small config it can work).
  3. Lastly, there are literal API Platforms that assist with this exact version control and maintenance - like IBM API Connect or Redocly - these also create Swagger UI’s for you and everything, very comprehensive. I don’t think you need this in your case, you use case is minor, just good to know if it scales quickly.
9

Ok, then makes sense to keep it in the same library as its one platform.

I then am still not seeing the strong need to any config mess.

Lets say you have a workflow for CreatePerson in your library,
One assumes the input arguments for that workflow match the DTO of the api call, but flattened out abit to make it easier to use, so perhaps an argument for FirstName, Surname, DOB etc.

The only other argument can be the environment as an enum, or simple string dropdown, of DEV / TEST / PROD.

The library itself can resolve the endpoint based on what environment you want to use.
Otherwise you can just let the library accept the endpoint as a URL and just use the relative endpoint for CreatePerson in the library.
In both instances I don’t see the need for any configs.

Am I missing something?