| name | uipath-coded-apps |
| description | UiPath Coded Apps — scaffold, build, run, and deploy Coded Web Apps and Coded Action Apps: React/TypeScript apps that call UiPath Cloud APIs via the `@uipath/uipath-typescript` SDK and ship to Automation Cloud (push/pull to Studio Web, pack, publish, deploy, OAuth-PKCE). Also generates live analytics & governance dashboards from a plain-language request, wired to tenant data via the Insights real-time API, with edit and deploy flows. For RPA→uipath-rpa, Python agents→uipath-agents, Maestro flows→uipath-maestro-flow, solution packaging→uipath-solution. |
| when_to_use | User wants to scaffold, build, push/pull, pack, publish, or deploy a Coded Web App or Coded Action App, or use the `@uipath/uipath-typescript` SDK inside one. Also dashboard requests: 'build me a dashboard', 'show agent health / error rate / KPIs / governance violations', 'generate an analytics or observability dashboard', edit an existing one (add/remove/change a widget, change time range, deploy), or fix/diagnose a dashboard that won't build (a metric that fails to compile, a bad SDK call, a broken widget). For RPA→uipath-rpa; Python agents→uipath-agents; Maestro flows→uipath-maestro-flow. |
| allowed-tools | Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion, Task |
UiPath Coded Apps
Build, debug, and deploy UiPath Coded Web Applications and Coded Action Apps using the uip codedapp CLI and @uipath/uipath-typescript SDK.
When to Use This Skill
- User wants to build, debug, or deploy a UiPath Coded Web App or Coded Action App
- User asks about
uip codedapp commands, .uipath/ directory, app.config.json, or action-schema.json
- User wants to scaffold a new React/Vue frontend for UiPath Cloud or an Action Center form
- User asks for app UI that a prebuilt UiPath widget covers: review/correct Document Understanding extraction results (Validation Station), chat with a conversational agent, browse/edit a Data Fabric entity in a grid, upload files to a storage bucket, display a PDF, or sign in with an external IdP (Google/SAML)
- User wants to push/pull source between local and Studio Web
- User wants to use the
@uipath/uipath-typescript SDK from a coded app
- User wants to run the full pipeline (build → pack → publish → deploy)
- User wants to generate an agent-monitoring / analytics dashboard from a natural-language description — e.g. "show agent health, error rates, invocation volume, latency, active agents, KPIs, governance metrics, or consumption trends"
- User says "build/create/generate a dashboard", describes metrics to visualize, or asks for an agent observability, operations, or cost view
App Types
| Type | Description | Key Difference |
|---|
| Coded Web App | React/Vue/other frontend hosted on UiPath CDN | User-facing app accessed via a URL |
| Coded Action App | React form wired to UiPath Action Center | Rendered inside human task reviews in Maestro/Agent workflows |
Two lifecycles, two scaffolding entry points.
- Standalone coded app: scaffold with
npx create-vite@latest (see create-web-app.md / create-action-app.md). No project.uiproj / webAppManifest.json — those are solution-membership artefacts and standalone apps don't need them. Deploy via uip codedapp pack → uip codedapp publish (-t Action for action apps) → uip codedapp deploy. This is the classic single-app lifecycle covered by the rest of this skill.
- In-solution coded app: run
uip codedapp init from inside a .uipx solution. Init writes project.uiproj (ProjectType: "AppV2") + webAppManifest.json, nests runtime + build artefacts under source/dist/, auto-registers the project as Type: "AppV2" in the .uipx, and emits resources/solution_folder/app/{Coded,CodedAction}/. From then on the app is part of the solution — uip solution pack bundles its .nupkg and uip solution deploy run provisions it in the deployment folder. Do not run uip codedapp pack / publish / deploy on a coded app that's already registered in .uipx — that bypasses the solution's deploy config (external client ID, routing name, action schema) and double-registers the package. uip solution projects add / uip solution projects import register existing AppV2 folders too, reading webAppManifest.config.isActionApp to pick the Coded / CodedAction subType. For the solution-side lifecycle see /uipath:uipath-solution.
uip codedapp init is for solutions only. It is not the scaffolding entry point for a standalone coded app — use create-vite for that.
Critical Rules
- Identify the app type before doing anything else. Ask as a structured choice (Rule 18): Coded Web App — custom frontend deployed to UiPath Cloud · Coded Action App — form for Action Center human task reviews. The two paths diverge on scaffolding, redirect URI, and publish flag — do not guess.
- Always check login status first. Run
uip login status --output json before any cloud command. If not logged in, run uip login.
- Never skip the build step. Run
npm run build after scaffolding (to verify the scaffold compiles) and again before pack or push (to produce the deployable dist/). Verify dist/ exists each time.
- Pack → Publish → Deploy order is required. Each step depends on the previous one producing its output.
- Bump the version for re-publish. If the same version already exists in Orchestrator, publish will fail.
- Action apps require
-t Action on publish. Run uip codedapp publish -t Action (not the default Web type).
- Never handle access tokens manually. Do not pass, print, parse, source, or set cached access tokens. Use
uip login and supported uip codedapp commands; the CLI manages authentication.
- Base URL must use the API subdomain.
https://api.uipath.com not https://cloud.uipath.com. See the table below.
vite.config.ts must always set base: './'. The platform handles URL routing — apps must use relative asset paths. Do not use a routing name or a sub-path here. Import static assets through the bundler (import logo from './assets/logo.png') so Vite fingerprints and base-rewrites them. Do NOT place them in public/ or reference them by a hardcoded /-rooted path — those bypass base rewriting and 404 after deploy under the non-root mount.
- Use
getAppBase() from @uipath/uipath-typescript for any absolute URL constructed at runtime — router basename, image src, fetch paths. Deployed apps mount at a non-root prefix; /-rooted paths work locally but 404 after deploy. Vite's only fixes import-time references.
Disambiguation — Apps vs Dashboards
Route directly to Apps workflow (sections below) when you see:
web app, action app, codedapp, app.config.json, action-schema.json,
scaffold app, deploy app, pack, publish, push, pull, debug app
Route directly to references/dashboards/CAPABILITY.md when you see:
dashboard, analytics, KPI, metrics, Insights, observability,
admin console, report, chart, trend, governance report, agent metrics
When intent is ambiguous — ask "Which fits your goal?" as a structured choice (Rule 18):
| Option | Description |
|---|
| Build or modify a Web App / Action App | Scaffold a UI, form, or app that deploys to Automation Cloud |
| Generate a dashboard | Analytics or admin view from a natural-language description |
Task Navigation
CLI Setup
npm install -g @uipath/cli
uip tools install @uipath/codedapp-tool
uip tools install @uipath/orchestrator-tool
uip tools list
UIP=$(command -v uip 2>/dev/null || npm root -g 2>/dev/null | sed 's|/node_modules$||')/bin/uip
$UIP --version
Authenticate before any cloud command:
uip login status --output json
uip login
uip login --authority https://alpha.uipath.com
uip login \
--client-id <id> \
--client-secret <secret> \
--organization <org> \
--tenant <tenant> \
--scope "OR.Default Apps.Read Apps.Write" \
--authority https://alpha.uipath.com
The uip login session scope is separate from the app's runtime OAuth scopes. The scopes in uipath.json are what the deployed app requests at runtime (see oauth-scopes.md). The --scope on uip login above is what the CLI session needs to call the Apps registration API during uip codedapp publish. uip codedapp publish does two things: uploads the package (needs OR.Default) and registers the coded app (needs Apps.Read Apps.Write). For what each failure looks like, see debug.md.
SDK Config (web app)
The web app initializes the SDK with new UiPath() (no config). At runtime the SDK reads clientId, scope, orgName, tenantName, baseUrl, and redirectUri from <meta name="uipath:*"> tags. During local dev @uipath/coded-apps-dev injects those tags from uipath.json (committed) — the single config source, holding clientId, scope, orgName, tenantName, baseUrl, and redirectUri (the Vite dev URL for local). In production the UiPath platform injects the same tags directly.
To change any of these values, edit uipath.json.
CLI Environment Variables
| Variable | Used By | Description |
|---|
UIPATH_PROJECT_ID | uip codedapp push / uip codedapp pull | Studio Web project ID |
Base URL by environment:
| Environment | Correct Base URL |
|---|
| Production (cloud) | https://api.uipath.com |
| Staging | https://staging.api.uipath.com |
| Alpha | https://alpha.api.uipath.com |
Quick Deploy (Full Pipeline)
Do NOT pause between steps to ask "should I continue?" — execute the full pipeline. Only stop if you need auth credentials or an app name.
- Auth —
uip login status --output json. If not logged in, ask the user for their environment and run uip login. With client credentials (headless/CI), use --scope "OR.Default Apps.Read Apps.Write" — all three names are required: OR.Default for Orchestrator, Apps.Read and Apps.Write for the Apps-service registration in uip codedapp publish. The External Application itself needs only Apps.Read and Apps.Write; OR.Default is auto-granted and not portal-selectable, so name it in --scope. If publish or deploy then fails, see debug.md.
- Build —
npm run build. Verify ls dist/.
- Pack —
uip codedapp pack dist -n <name> --version <version>. Produces .uipath/<name>.<version>.nupkg. Bump version if previously published.
- Publish —
uip codedapp publish (add -t Action for action apps). Verify cat .uipath/app.config.json.
- Deploy —
uip codedapp deploy -n <name> --folder-key <GUID>. Resolve the GUID from the chosen folder: a personal workspace (Type == "Personal"), a named existing folder, or a freshly uip or folders created one — via uip or folders list --output json. Dashboards additionally choose a deploy mode (standalone / governance-pinned / governance) that sets --tags; see dashboards deploy impl. Never let the command go interactive. Share the app URL with the user.
SDK Module Imports
See references/sdk/imports.md for the lookup protocol (subpaths and classes are discovered from the installed package — ls node_modules/@uipath/uipath-typescript/dist/), type import conventions, and anti-pattern examples. Core rules are listed under Anti-patterns below.
Key Concepts
App Config (.uipath/app.config.json)
Created by publish, consumed by deploy. Contains appName, systemName, appType, deploymentId, appUrl. Do not delete .uipath/ between publish and deploy.
Action Schema (action-schema.json)
Action apps define a data contract between the form and the Maestro/Agent workflow. It has four sections: inputs (read-only data from automation), outputs (user-filled fields), inOuts (pre-populated but editable), and outcomes (submission buttons like Approve/Reject).
Troubleshooting
See references/debug.md for detailed diagnosis steps.
| Error | Cause | Fix |
|---|
Not authenticated | No valid session | Run uip login |
dist/ not found | App not built | Run npm run build |
Published app with package name '<name>' and version '<version>' already exists | Same name+version already published (registration rejects duplicates) | Bump --version and re-publish |
Folder key required / deploy hangs on prompt | Missing folder for CLI deploy | Resolve folder name → key via uip or folders list --output json (match on Name, read Key), then run uip codedapp deploy --folder-key <GUID> .... See pack-publish-deploy.md. |
No packages found | No .nupkg in .uipath/ | Run pack first |
| Login fails / redirect error | OAuth misconfiguration | See debug.md |
| API calls fail with 401/CORS | Wrong base URL | Use https://api.uipath.com not cloud.uipath.com |
Folder identifier names differ across CLI and SDK. The CLI uses UIPATH_FOLDER_KEY / --folder-key (string) and applies only to uip codedapp deploy. SDK methods use different parameters: Maestro services (MaestroProcesses, ProcessInstances, Cases) take folderKey (string GUID), Orchestrator services (Assets, Queues, Buckets, Processes) take folderId (number). Do not pass the CLI env var into SDK calls. To bridge from a Maestro folderKey to an Orchestrator folderId, see sdk/maestro.md — and never parseInt(folderKey), the GUID is not numeric.
Completion Output
When you finish a task, report only what's applicable to the work actually done:
- What was done — files created, edited, or deleted (list paths); CLI commands run
- Stage reached — one of: scaffolded / built / packed / published / deployed
- Artifacts produced (report only the ones that actually exist):
dist/ — if npm run build was run
.uipath/<name>.<version>.nupkg — if pack was run
.uipath/app.config.json with deploymentId — if publish was run
- Live deployment URL (
appUrl from app.config.json) — if deploy was run
- External Application client ID — if one was created this session
- Next steps, depending on where the task stopped:
- Scaffolded only:
cd <app-name> && npm run dev to run locally
- Built but not packed: ready to
uip codedapp pack when the user wants to deploy
- Published but not deployed: run
uip codedapp deploy to go live
- Deployed (Web): open/share the deployment URL; verify sign-in flow
- Deployed (Action): the app will render in Action Center human tasks triggered by Maestro/Agent workflows matching the routing name
- Open issues — any auth failures, scope mismatches, missing folder key, skipped steps, or errors left unresolved
If a later stage was requested but skipped (e.g., user asked to deploy but only publish succeeded), call it out explicitly in the next-steps section.
Anti-patterns
These pitfalls are not already covered by the Critical Rules. For rules stated as positive requirements, see the Critical Rules section at the top.
- Don't import service classes from the package root — use the subpath (e.g.,
@uipath/uipath-typescript/assets).
- Don't use the deprecated dot-chain
sdk.entities.getAll() — use constructor DI: new Entities(sdk).
- Don't delete
.uipath/ between publish and deploy — deploy reads app.config.json written by publish.