> For the complete documentation index, see [llms.txt](https://docs.buzzy.buzz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buzzy.buzz/developing-and-extending-buzzy/buzzy-rest-api/rest-api/microapp-data-operations/updatemicroapprow.md).

# updatemicroapprow

### description

Modify an existing row in a Microapp. The JSON body consists of rowID and rowData. The field names need to match (case sensitive) to the Buzzy field labels.

Use [Row Metadata and Relationships](/developing-and-extending-buzzy/buzzy-rest-api/rest-api/microapp-data-operations/row-metadata-and-relationships.md) for the canonical explanation of row metadata, linked-table values, and parent-child relationships.

### parameters

The `X-Auth-Token` and `X-User-Id` are derived from the values `authToken` and `userId` returned from the login endpoint and are used in the HTTP header.

Accepted top-level request properties:

* `rowID` - required. Row to update.
* `rowData` - required. JSON object whose keys match Datatable field labels exactly.
* `embeddingRowID` - optional. Attempts to move the row under a different parent row.
* `userID` - optional. Attempts to change the row creator.
* `ignoreActionRules` - optional boolean passed through to field updates.

Unknown keys inside `rowData` are ignored. System metadata such as `_id`, `submitted`, `clientSubmitted`, `parentResourceID`, and `topLevelParentID` is not writable through `rowData`.

#### Resource

```json
{
  "rowID": "<insert microapp row id here>",
  "embeddingRowID": "<optional new parent row id>",
  "userID": "<optional new creator user id>",
  "ignoreActionRules": true,
  "rowData": {
    "ExampleFieldName": "ExampleValue"
  }
}
```

### response

Returns the status of the request

### Basic Update Example

```
POST /api/updatemicroapprow 
X-Auth-Token:<insert token here>
X-User-Id:<insert user id here>

{
    "rowID": "<insert row ID here>",
    "rowData": {
        "Name": "Updated Organization Name"
    }
}
```

### Linked Table Field Update Example

When updating linked table (cross app) fields, provide the complete linked field structure:

```
POST /api/updatemicroapprow 
X-Auth-Token:<insert token here>
X-User-Id:<insert user id here>

{
    "rowID": "<insert row ID here>",
    "rowData": {
        "assignedUser": {
            "crossAppRowID": "new-user-row-id",
            "value": {
                "label": "name", 
                "value": "Jane Doe"
            }
        },
        "marketplaceListing": {
            "crossAppRowID": "listing-row-id",
            "value": {
                "label": "listingName",
                "value": "Advanced AI Analytics Platform"
            }
        }
    }
}
```

**Important Notes:**

* To update a linked table field, provide the new `crossAppRowID` and corresponding `value`
* To clear a linked table field, set the field to `null`
* The `value.label` should match a field name in the linked table
* The `value.value` should be the display value from that field

You should get back:

```
{
    "status": "success"
}
```

### Metadata Update Example

This example shows the supported top-level metadata updates:

```http
POST /api/updatemicroapprow
X-Auth-Token:<insert token here>
X-User-Id:<insert user id here>

{
  "rowID": "<insert row ID here>",
  "embeddingRowID": "<new parent row id>",
  "userID": "<new creator user id>",
  "ignoreActionRules": true,
  "rowData": {
    "Name": "Updated Organization Name"
  }
}
```

### what you can and can't change

* You can update business fields by sending their labels in `rowData`.
* You can clear a normal field by setting that field to `null`.
* You can change the row creator with top-level `userID`, but only when the caller can edit the top-level parent resource of the Datatable.
* You can attempt to move the row to a different parent with top-level `embeddingRowID`, but the move is only applied if the target parent row exists and the caller is allowed to add embedded rows there.
* Viewer and Team Viewer fields are updated through `rowData` using the actual field label in the Datatable, not through top-level `viewers` or `teamViewers` properties on this endpoint.
* You cannot update arbitrary metadata like `_id`, `submitted`, `clientSubmitted`, `parentResourceID`, or `topLevelParentID` through `rowData`.
* If `rowData` includes keys that do not match a field label exactly, those keys are ignored.

### See Also

* [Row Metadata and Relationships](/developing-and-extending-buzzy/buzzy-rest-api/rest-api/microapp-data-operations/row-metadata-and-relationships.md) - Canonical metadata, `embeddingRowID`, and linked-table semantics
* [Common API Examples](/developing-and-extending-buzzy/buzzy-rest-api/rest-api/common-api-examples.md#update-a-contact) - See this operation in all three API formats
* [microappdata/row](/developing-and-extending-buzzy/buzzy-rest-api/rest-api/microapp-data-operations/microappdata-row.md#linkedtable-crossapp-row-field-example) - Understanding linked table field structure
* [insertmicroapprow](/developing-and-extending-buzzy/buzzy-rest-api/rest-api/microapp-data-operations/insertmicroapprow.md#linked-table-field-example) - Inserting linked table fields

***