# 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.

Example:

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

| Field | Purpose |
|---|---|
| `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:

![Coded app project synced in Studio Web, with the resource tree in the Explorer panel and the Configuration panel showing Project ID, version, and last-pushed date](https://dev-assets.cms.uipath.com/assets/images/studio-web/coded-apps/bindings-panel-registered-e3a665ad.png)

## 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](https://docs.uipath.com/studio-web/automation-cloud/latest/user-guide/about-solutions).

## Best practices

* 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.