Build the API workflow

Build a Monster Query API Workflow that calls the 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 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. In the Start building dialog, choose API Workflow under Task automation.

Selecting the type creates the project immediately, with no name prompt, so you rename it in the next step.

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

1. In the workflow canvas, select + between activities to open the activity menu. Select HTTP. The activity appears on the canvas as HTTP Request.
2. Open the activity context menu and select Rename. Name it HTTP Request - Open5e Monster Query.
3. In the Properties pane, confirm Authentication is Manual authentication and Method is GET. Both are the defaults on a new activity, so there is normally nothing to change.
4. Set URL to https://api.open5e.com/v2/creatures/.
5. Rename the activity output to searchResults.

Set the Query parameters property:

Open the Query parameters property, which opens a Dictionary editor with Key and Value columns, and add the following fields:

Key	Value
name__icontains	the searchName input argument - see the warning below
document__key	srd-2014
limit	10
fields	key,name,type,size,challenge_rating,alignment

Warning:

name__icontains takes the searchName variable, and you must pick it from the variable picker rather than typing it. In the value field, start by typing @ to open the picker and select searchName - not using the picker will send the input as a literal string, and the API will return HTTP 200 with no results. The field then renders the value as a chip, and the stored value is $input.searchName.

What each parameter does:

• name__icontains: case-insensitive partial match; dragon returns "Adult Red Dragon", "Young Blue Dragon", and others
• document__key: srd-2014: filters to the official 5e SRD; without it, results include every publisher in the database, third-party content included
• limit: 10: caps candidates at 10; enough for the agent to reason over without flooding its context
• fields: limits the response to only the fields the agent needs; the full v2 creature object is much larger and would waste token budget

Warning:

Open5e ignores query parameters it does not recognize, and returns HTTP 200 anyway. Misspell document__key, or use the v1 spelling document__slug, and the filter is silently dropped: the call succeeds, the run is green, and the agent receives creatures from every publisher instead of the SRD. A goblin search returns 2 results with the filter applied and 29 without it, so check that the result count looks like a handful rather than a catalogue.

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/json to 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. To reference a workflow argument, enter @ to open the variable picker and select the argument - the field stores $input.<name> and displays it as a chip. @ is the picker's trigger character, not a reference syntax you can type out. 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 Response expression readable.

Add the response

1. In the workflow canvas, select + after the HTTP Request and select Response.

   The Response activity 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.

2. Set the response body to:

   {
     "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

1. Select Debug from the toolbar.
2. In the input panel, set searchName to dragon or goblin and run the workflow.
3. Verify the response includes a monsterResults array with monster entries before continuing.

A successful response contains up to 10 entries, each with key, name, alignment, and challenge_rating, plus nested type and size objects. Searching goblin returns Goblin and Hobgoblin. 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.

1. Select Publish from the toolbar.
2. 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.
3. Select Publish to confirm.

Note:

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.