Possibilities when triggering process via Orchestrator API with file as input

[MKR]

Hello UiPath Community,

I have done a lot of research on this topic, so my question is just regarding the latest advancements regarding this topic, as well as a summary / open discussion regarding the possibilities and the best approach in this kind of a scenario. Below I have linked some discussion threads I have gone over, when researching this matter.

The scenario: A process will be triggered using the orchestrator endpoint. 3 excel / csv files need to be passed as input. Accessing the files from their file location is not an option, the file / content has to be passed via the API call. The process will be called many times per day, about 100 times to start with but that can multiply by 10 in the future. The process needs to be scalable.

The possibilities I looked into / found:

• Sending the files as input arguments: Based on my research, this is currently not possible in UiPath. Please let me know if there have been any new advancements making this possible as an option.
  How to pass pdf file as argument while invoking an automation process via API calls provided by UiPath? - Help / Studio - UiPath Community Forum
  Arguments for Job - Help - UiPath Community Forum
• Sending the file content as text (converting to Base64 String). Based on my research this is possible, but I have a couple of concerns:
  • The maximum limit of ‘10000’ characters. I don’t have info on the size of the files and I have concerns about the payload drastically increasing during conversion.
    Start a Job with file attachments - Help / Orchestrator - UiPath Community Forum
  • Data loss; Do you have any ideas on how to check that we don’t loose any content during the handover?
  • Data loss in the case of an error causing the job not to be triggered successfully; Since the BOT will be receiving raw data rather than a file that will be stored somewhere, this is a concern of mine.
  • Any other concerns you can think of?
• Using storage buckets (calling the storage buckets endpoint first to store the file there, and then triggering the bot with the storage bucket file ID as input). This is currently looking like the best option, but I still have some areas of concern:
  • Storage bucket’s capacity. I worry about size limitations, since this needs to be a scalable. I plan on having the BOT delete the file once it’s done with it, but this is still an area of concern since we might be dealing with a lot of files in the future.
    Storage buckets - how it works? - Help / Orchestrator - UiPath Community Forum
    Is there a size limit to the storage bucket? - News / Knowledge Base - UiPath Community Forum
  • Efficiency. I assume this solution will be less efficient than the previous one. I worry about the execution time.
  • Data buckets configuration. This seems pretty straight forward, but are there any concerns I should be aware of?

I am open to other suggestions and any contributions to this discussion. Thank you so much!

• M

[Anil_G (Anil Gorthi)]

@MKR

Storage bucket is your best option for now…

Also apart from that you can leverage a gdrive,sharepoint ,box,Azure blob or any ftp as well if you have access to any of these

first and second approaches are obselete

cheers

[ravindra.reddy33 (Ravindra Reddy Madireddy)]

I agree with @Anil_G

For this scenario, I would recommend using Storage Buckets.

Passing the actual Excel/CSV files directly as input arguments is not a good/scalable option, and Base64 can work only for small files but may hit size limits and increase payload size.

A better approach is:

1. Upload the files to a UiPath Storage Bucket using the API.
2. Start the job and pass only the bucket path / file reference / IDs as input arguments.
3. In the process, download/read the files from the bucket.
4. Delete or archive the files after successful processing.

This is more scalable and safer because the files are stored before the job starts, so you reduce the risk of data loss if the job fails to trigger. You can also add logging/status tracking around upload, job start, processing, and cleanup.

For high volume, I would also suggest using unique file names/folders per transaction and having a cleanup/retry mechanism in case a job fails before deleting the files.