- Overview
- Getting Started with UiPath Agents
- Getting Started with UiPath Agents using LangGraph
- Building a Low-Code Agent in Studio Web
- Adding Tools to Your UiPath Agent
- Introduction
- Build the API workflow
- Connect to your agent
- Test end-to-end
Build a Monster Query API Workflow that calls the D&D 5e SRD and returns structured monster data.
Step 1 - Build the Monster Query API workflow
An API Workflow is a lightweight workflow published as an API endpoint. You build one that wraps the Open5e D&D 5e SRD monster search: one input, one HTTP request, one output. Once published, it appears in the agent builder as a tool your agent can call.
This step has six sub-steps; budget 10–15 minutes to complete it.
Create a new API workflow project
Select Create New from your Cloud Workspace and choose API Workflow as the project type.
Rename the solution and the default workflow. Open the context menu for each name in the project explorer and select Rename:
- Solution name:
Monster Query - 5e SRD - Workflow name:
API Query - 5e Monsters
Configure inputs and outputs
Select the Data Manager (clipboard icon along the left rail) to access the data variables for the workflow.
Add one input argument to the workflow:
| Name | Type | Required | Description |
|---|---|---|---|
searchName | String | Yes | The monster name or partial name to search for |
Add one output argument:
| Name | Type | Required | Description |
|---|---|---|---|
monsterResults | Array | Yes | Monster result list |
Add the HTTP request
- In the workflow canvas, select + between activities to open the activity menu. Select HTTP Request.
- Open the activity context menu and select Rename. Name it
HTTP Request - Open5e Monster Query. - In the Properties pane, set Authentication to Manual authentication.
- Set Method to GET.
- Set URL to
https://api.open5e.com/v1/monsters/. - Rename the activity output to
searchResults.
Set the Query Parameters property:
Open the Query Parameters property and add the following fields:
| Key | Value |
|---|---|
name__icontains | @searchName |
document__slug | wotc-srd |
limit | 10 |
fields | slug,name,desc,type,size,cr,challenge_rating,alignment,v2_converted_path |
What each parameter does:
name__icontains: case-insensitive partial match;dragonreturns "Adult Red Dragon", "Young Blue Dragon", and othersdocument__slug: wotc-srd: filters to the official D&D 5e SRD; without it, results include third-party homebrew contentlimit: 10: caps candidates at 10; enough for the agent to reason over without flooding its contextfields: limits the response to only the fields the agent needs; the full Open5e monster object is much larger and would waste token budget
HTTP Request property reference
The activity exposes the standard HTTP building blocks. Most you will configure for every API you call; some you will skip for public APIs like this one:
- Authentication: pre-built options for OAuth 2.0, API key, and Basic auth. Set to "Manual authentication" here because Open5e requires none. For authenticated APIs, choose the appropriate option and supply credentials.
- Headers: key/value pairs sent with every request. Common uses:
Authorization: Bearer <token>for token-based APIs,Accept: application/jsonto control response format, and API versioning headers. - Body: used with POST, PUT, and PATCH requests to send JSON, form data, or raw content. Not applicable for GET requests, which carry parameters in the URL via query parameters.
- Query Parameters: key/value pairs appended to the URL. The
@variableNamesyntax references workflow arguments by name;@searchNamepulls in thesearchNameinput argument defined in the Data Manager. See configuring activities for more on variables and expressions in Studio Web. - Output (renamed to
searchResults): receives the full HTTP response including status code, headers, and body. Renaming from the default keeps the Set Response expression readable.
Add the response
-
In the workflow canvas, select + after the HTTP Request and select Set Response.
Set Response defines what the API Workflow returns to its caller (in this case, what the agent's tool receives when it invokes the workflow). Whatever you put in the response body here becomes the tool output the agent reasons over.
-
Set the response body to:
{ "monsterResults": $context.outputs.searchResults.content.results }{ "monsterResults": $context.outputs.searchResults.content.results }
$context.outputs contains every named output from the activities in this workflow. searchResults is the output variable you renamed on the HTTP Request activity; .content.results navigates into the response envelope that Open5e wraps its data in, down to the actual array of monster entries. For more information, check out the UiPath documentation on using Javascript to access workflow data.
Test the workflow
- Select Debug from the toolbar.
- In the input panel, set
searchNametodragonorgoblinand run the workflow. - Verify the response includes a
monsterResultsarray with monster entries before continuing.
A successful response contains up to 10 entries, each with fields like name, type, cr, and slug. If you see an empty array, try a different search term; not every creature name has an exact match in the SRD.
Publish to your feed
Publishing registers the workflow as a deployable process in Orchestrator. This is what makes it discoverable in the agent builder's Available resources list: the builder surfaces published workflows from your workspace, not drafts saved locally in Studio Web.
- Select Publish from the toolbar.
- In the publish dialog, select For me to publish to your personal workspace feed. A personal workspace feed is a private package repository tied to your Orchestrator workspace; publishing "For me" makes this workflow visible only to you, which is the right scope for development and testing. See Personal Workspaces in the UiPath docs for details.
- Select Publish to confirm.
Workflow not appearing in Available resources in Step 3? The workflow must be published (not just saved) before it is visible as a tool. If it does not appear, return here and confirm the publish completed successfully, then refresh the agent builder.
With the workflow published, it is available in the agent builder as a connectable tool in the next section.