21.2 API Workflows in Studio Web

21.2 API Workflows in Studio Web

Core Concept: API workflows are headless workflows built in Studio Web that chain API calls and transform data on UiPath's cloud-managed, serverless infrastructure. They run fast, need no robot machine, and can serve as reusable APIs, as tools for agents, or as tasks in Maestro processes.

---

API Workflows Versus RPA Workflows

---

The Activities

Tips from UiPath's documentation:

• Define clear input and output schemas, so other UiPath products can call the workflow correctly.
• Inside For Each and Do While, use $input instead of $context to access the previous object's output.
• Use Autopilot to generate context-aware JavaScript expressions, and validate them in the expression editor's output panel before running.
• Test quickly with the Run Output panel, which shows inputs and outputs you can expand or copy.

---

Outbound Traffic and IP Allow Lists

Calls inside the UiPath platform, for example to Orchestrator, need no allow-listing. External calls do, and the source depends on the activity:

If a partner's firewall blocks requests, check which path the activity uses and allow the matching IP range.

---

Publishing and Consuming

• From Orchestrator: publish the API workflow; it appears as a process. Start a job from Automations > Processes, supply the input (the request schema), and read the response in the job details.
• As an agent tool: add it to an agent with Add tool > API workflow and describe its inputs clearly so the agent can call it. The agent then uses only the data the API workflow returns, which limits what the model sees.
• In Maestro: use API workflows as tasks that encapsulate API chaining and data transformation, keeping the main process readable.

---

Worked Example: Enriching a New Lead

1. Input schema: email (string).
2. Connector activity: search the CRM for a contact with that email.
3. If the contact exists, Response with Success and the contact ID.
4. Otherwise, an HTTP activity with manual authentication calls a company-data API.
5. A Script activity maps the response to the CRM's fields in JavaScript.
6. A Connector activity creates the contact.
7. Try Catch around steps 4 to 6 returns a Failure response with a clear message if the external API fails.
8. Response with Success and the new contact ID.

The workflow runs in a few seconds without any robot machine, and the sales agent that calls it as a tool never sees the raw data from the external API.

---

Design Guidelines

• Keep each API workflow focused on one integration task with a clear contract, so it can be reused by processes, agents, and Maestro alike.
• Validate inputs first and return a Failure response with a clear message when required values are missing.
• Handle partial failures: decide what happens if the second of three API calls fails, and use Try Catch to return a meaningful response.
• Log identifiers, not payloads, to keep sensitive data out of logs.
• Prefer connectors when one exists, because they manage authentication and tokens; use manual HTTP only when necessary.

---

Key Terms

• Input and output schema: the JSON structure of the request and response, which callers such as agents rely on.
• $context and $input: expression variables for accessing workflow data; inside loops, $input holds the previous object's output.
• Run Output panel: the design-time view of each activity's inputs and outputs during a test run.
• Platform connector: a connector for UiPath services, such as Orchestrator or Data Fabric, used from API workflows.

---

Common Traps

• Writing VB.NET expressions: API workflows use JavaScript.
• Forgetting to allow serverless IPs for manual HTTP calls to firewalled systems.
• Using $context inside loops where $input holds the previous object's output.
• Trying to automate a UI: API workflows cannot; use an RPA workflow.