Bindings and runtime resources

Bindings in coded apps, covering how UiPath resources are declared in bindings_v2.json and registered by Studio Web on push.

A coded app is rarely self-contained — it typically calls out to Orchestrator resources such as assets, storage buckets, queues, connections, or other automation projects. Studio Web uses a bindings_v2.json file, shipped with your app's source, to declare, resolve, and override those references at deploy time.

What bindings are

A binding is a logical reference from your coded app to a UiPath resource. It has two parts:

• A declaration inside bindings_v2.json, at the root of what you push. Each entry names a resource, its type, and a default value.
• A concrete resolution to an Orchestrator entity — folder, asset, bucket, queue, connection, or process — decided at deploy time by the solution's environment configuration.

Because the declarations in bindings_v2.json are stable, the same coded app can be deployed to development, staging, and production without code changes.

Declaring bindings in bindings_v2.json

A bindings_v2.json file at the root of what you push declares the bindings. It follows a versioned schema with a top-level resources array; each entry describes one binding.

Exemple :

{
  "version": "2.0",
  "resources": [
    {
      "activityDisplayName": "Get Asset",
      "activityId": "GetRobotAsset_1",
      "resource": "asset",
      "key": "Asset",
      "id": "assetAssetAssetFalse",
      "value": {
        "name": {
          "defaultValue": "Asset",
          "isExpression": false
        }
      },
      "metadata": {
        "BindingsVersion": "2.2"
      }
    },
    {
      "activityDisplayName": "Invoke Process",
      "activityId": "InvokeProcess_1",
      "resource": "process",
      "key": "Arghya-Queue-Query",
      "id": "processArghya-Queue-QueryArghya-Queue-QueryFalse",
      "value": {
        "name": {
          "defaultValue": "Arghya-Queue-Query",
          "isExpression": false,
          "displayName": "Process name"
        }
      },
      "metadata": {
        "BindingsVersion": "2.2"
      }
    },
    {
      "activityDisplayName": "Add Queue Item",
      "activityId": "AddQueueItem_1",
      "resource": "queue",
      "key": "Arghya_query_queue",
      "id": "queueArghya_query_queueArghya_query_queueFalse",
      "value": {
        "name": {
          "defaultValue": "Arghya_query_queue",
          "isExpression": false
        }
      },
      "metadata": {
        "BindingsVersion": "2.2"
      }
    }
  ]
}

Fields per resource

Champ	Objectif
activityDisplayName	Human-readable label shown in Studio Web's Resources panel.
activityId	Stable identifier the SDK uses to look up the binding at runtime.
resource	Resource type: asset, bucket, queue, connection, process, and so on.
key	The resource's key or logical name inside the app.
id	A composed identifier used by Studio Web to persist and diff bindings across pushes.
value.name.defaultValue	The default Orchestrator entity name to resolve to before environment overrides are applied.
value.name.isExpression	true if defaultValue is an expression to be evaluated, false for a literal.
metadata.BindingsVersion	Per-resource schema version.

Registering bindings on push

Every uip codedapp push re-reads bindings_v2.json. Studio Web loads the file from the pushed content and registers each entry from the resources array under the project's Resources panel. Existing bindings whose id is unchanged retain their environment mappings; new entries appear unmapped until you map them.

If bindings_v2.json is absent from what you push, the project has no bindings and the Resources panel is empty.

Once the push completes, the project view in Studio Web confirms the sync and lists each registered resource type:

Mapping bindings to Orchestrator resources

For each registered binding, you (or the solution's environment configuration) select a matching Orchestrator resource — for example, mapping a Get Asset binding to a specific credential asset in a chosen folder.

The mapping is stored as part of the solution's environment configuration, not inside the pushed source. This is how a single coded app package is safely promoted across development, staging, and production — each environment provides its own resolutions.

For managing environments, see About solutions.

Meilleures pratiques

• An activityDisplayName should be intent-revealing (Get Payment API Key, not Get Asset) — it appears in the Resources panel and in every environment mapping.
• An activityId should stay stable across pushes. Studio Web relies on it (combined with id) to diff and retain environment mappings between pushes.
• A minimal bindings_v2.json is easier to maintain: every entry becomes a resolution requirement in every environment the app is deployed to.
• bindings_v2.json is source code and should live in Git alongside the rest of the app.