About UIPath API Workflow Capabilities in Studio Web

Dear Team,

I am currently exploring UiPath API Workflows in Studio Web and have encountered some limitations in functionality. Specifically, I have been unable to locate the following features:

  1. Database Activities - I cannot find database-related activities to work with data sources directly within API workflows.

  2. Invoke Workflow File/Process - I’m unable to find the option to invoke or call other workflow files or processes from within an API workflow.

  3. Exception Handling Activities - I cannot locate the Throw activity or other exception handling mechanisms to manage errors and exceptions in API workflows.

Could you please clarify what capabilities and activities are available for API Workflows in Studio Web? What are the intended use cases and limitations of API Workflows compared to traditional automation workflows?

Requirment:
i need to do Api calls and do some data manipulation using database activities and exception handling as usual and finally pushing to orchestrator queue.

Thank you for your support

@lakshminarayana_chavala

The features you mentioned are indeed not available in API Workflows by design.

API Workflows in Studio Web are a lightweight, serverless workflow type designed to run in the cloud (Automation Cloud) without an Unattended Robot. They are optimized for:

  • REST/HTTP API orchestration
  • System-to-system integrations (SaaS ↔ SaaS)
  • Lightweight data transformations (JSON/objects)
  • Triggering downstream automations (e.g., adding items to Orchestrator queues)

Because they execute in a managed serverless runtime (not on a Windows robot), several classic Studio Desktop activities are intentionally unavailable.

These rely on ODBC/OLEDB drivers on a Windows runtime. API Workflows run serverless in the cloud.

API Workflows can, however, call other API Workflows or start a Process on Orchestrator via activities like Start Job / Invoke Workflow (API-workflow-to-API-workflow).

Exception handling is built-in at the step level β€” each activity has automatic error propagation and you can use the β€œOn Error” / retry properties, but explicit Throw/Try-Catch blocks are limited.

The main activity groups you do have in Studio Web API Workflows include:

  • HTTP Request (GET/POST/PUT/DELETE with auth, headers, body)
  • Integration Service connectors (Salesforce, ServiceNow, SAP, Workday, Google, Microsoft 365, etc.)
  • Orchestrator activities β€” Add Queue Item, Start Job, Get Assets
  • Control flow β€” If, Switch, For Each, Parallel
  • Data manipulation β€” Assign, Deserialize JSON, expressions
  • Invoke API Workflow (call another API workflow)
  • Log Message

Option A β€” Hybrid (Recommended)

  1. API Workflow (Studio Web) β€” handle the external API calls, JSON parsing, and lightweight data manipulation.
  2. Add Queue Item activity (available in API Workflows) β€” push the transformed payload directly to an Orchestrator queue.
  3. Unattended/Attended Process (Studio Desktop) β€” a queue-triggered process consumes the items and performs the Database activities and structured Try/Catch exception handling you need.

This keeps API Workflows doing what they do best (integration) and delegates DB + robust error handling to a classic RPA process.

Option B β€” Pure API Workflow (only if DB access is via REST)

If your database exposes a REST endpoint (e.g., via an API layer, Azure SQL REST, Supabase, PostgREST, or an internal microservice), you can:

  • Use HTTP Request activity for both the source API and the DB API.
  • Do transformations inline.
  • Use Add Queue Item to push to Orchestrator.
  • Rely on per-activity error settings for exception handling.

Rephrased with AI but the concepts and data is validated by me

Thank you @ashokkarale for your info