Creates new 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 to list them all. None of the fields are required, if they are not provided the value is going to be null or false or some default value is that is set. If you want to add a value for the field with for example id 10, the key must be named field_10. Or instead if the user_field_names GET param is provided the key must be the name of the field. Of course multiple fields can be provided in one request. 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 created webhooks.
Path parameters
Creates the rows in the table.
Query parameters
If provided then the newly created rows will be positioned before the row with the provided id.
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 created 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.