Updates existing rows in the table if the user has access to the related table's workspace. The accepted body fields are depending on the fields that the table has. For a complete overview of fields use the list_database_table_fields endpoint to list them all. None of the fields are required, if they are not provided the value is not going to be updated. When you want to update a value for the field with id 10, the key must be named field_10. Or if the GET parameter user_field_names is provided the key of the field to update must be the name of the field. Multiple different fields to update can be provided for each row. In the examples below you will find all the different field types, the numbers/ids in the example are just there for example purposes, the field_ID must be replaced with the actual id of the field or the name of the field if user_field_names is provided.
WARNING: This endpoint doesn't yet work with row updated webhooks.
Path parameters
Updates the rows in the table.
Query parameters
if provided, this will include metadata key containing operation metadata information in the response. Metadata will include a list of field ids, that were changed during the operation. The list will be stored in update_field_ids key in metadata object. Also, metadata object will include cascade_update key with a list of rows updated in cascade, and a list of field ids that were updated in cascade update.
A flag query parameter that triggers webhooks after the operation, if set to y, yes, true, t, on, 1, or left empty. Defaults to true
A flag query parameter that, if provided with one of the following values: y, yes, true, t, on, 1, or an empty value, will cause this endpoint to expect and return the user-specified field names instead of the internal Baserow field names (e.g., field_123).
Provide if the rows are updated in a view. This can result in different permission checking and default values.
Headers
An optional header that marks the action performed by this request as having occurred in a particular client session. Then using the undo/redo endpoints with the same ClientSessionId header this action can be undone/redone.
An optional header that marks the action performed by this request as having occurred in a particular action group.Then calling the undo/redo endpoint with the same ClientSessionId header, all the actions belonging to the same action group can be undone/redone together in a single API call.