Resources · n8n integration

Baserow n8n integrationAutomate Baserow with n8n.

A Baserow table can be read and written by a workflow instead of by hand. The Baserow n8n integration is one node, one resource called Row and 8 operations, from a single create to batches of up to 200 rows. No trigger node exists, so a schedule or another app opens the run. Built for the person wiring it up.

Try the Baserow integration on n8n See the 8 operations

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the Baserow n8n integration actually do?

The Baserow n8n integration connects a Baserow database to every other app in a workflow, which is a chain of automated steps, through a single node that ships with n8n. That node talks to the Baserow API, the programmatic door to your data, on one resource called Row, and covers 8 operations: create, read, update and delete rows one at a time or in batches of up to 200 rows per request. Nothing to install, on n8n Cloud or on a self-hosted instance.

First scenario, an intake table that fills itself. A form answer or an inbound message lands in the workflow, row.create writes it into the table with its new identifier, and the rest of the branch takes over. Teams often run that branch against Google Sheets first, then swap the node once the spreadsheet stops holding up.

Second scenario, a nightly enrichment. A Schedule Trigger wakes the workflow at a fixed interval, row.getAll pulls the rows that still lack data, a lookup step finds what is missing, and row.batchUpdate writes the answers back 200 rows per request instead of one call per line. Anyone arriving from Airtable will recognize the shape, with the hosting question answered differently.

Third scenario, the end-of-cycle cleanup. row.getAll lists the rows ready to archive, row.batchDelete collects their identifiers from the incoming items, and the working table stays readable. When the same records also belong in a relational store, one execution can push a copy into Postgres.

The HTTP Request node takes over as soon as the job leaves the Row resource. Creating a table, editing a field, reading the structure of a database: the dedicated node does none of that, while HTTP Request calls any endpoint of the Baserow API and reuses the same credential, the access you register once in n8n, through predefined authentication.

Two limits are worth knowing before you build. Baserow has no trigger node in n8n, so a workflow starts from a Schedule Trigger, from an n8n Webhook, a URL that n8n exposes and another service calls, or from the trigger of another tool. And batch operations stop at 200 rows per request, so a large import becomes several calls in a loop. Both tradeoffs come back in the n8n review, and the patterns are drilled in the n8n training.

Connect

How do you connect Baserow to n8n?

01
Set the Host first
Both authentication methods start with the same field. Host stays on https://api.baserow.io for an instance hosted by Baserow, and takes the API URL of your own instance when Baserow runs on your servers. The credential itself is created once in the Credentials menu of n8n, and every Baserow node in every workflow then picks it from a dropdown.
02
Log in with a user account
Basic auth reuses an existing Baserow account. Username and Password are the ones that account logs in with, so the node sees exactly what the person behind it sees, no more and no less. A dedicated automation account is easier to live with than a personal login, which stops working the day that person leaves.
03
Or create a database token
The token route avoids handing a password to a workflow. In Baserow, log in, click your workspace in the top left corner, open My Settings, then Database tokens, and click Create token. A token needs a Name and a Workspace, so its reach ends at that workspace. Paste it into the Database Token field in n8n.

Actions

What each Baserow operation does in n8n

The Baserow node exposes 8 operations across 1 resources. For each one: the node as you configure it in n8n, the required fields, and our field notes.

Resources × operations matrix
Resource	Create	Get	Get Many	Update	Delete	Batch Create	Batch Delete	Batch Update
Row	✓	✓	✓	✓	✓	✓	✓	✓

Row

8 operations

Create multiple rows

row.batchCreate

What you see in n8n

Notes & use cases

Writes several rows into one table in a single request, up to 200 at a time, and returns each row it created.

Key parameters

Table Name or ID: the destination table, chosen from the dropdown or set by expression, for example {{ $json.tableId }}.
Data to Send: autoMapInputData sends incoming properties to the columns that carry the same names, defineBelow fills the Rows collection by hand.
Inputs to Ignore: comma-separated properties that stay out of Baserow, useful when earlier nodes add technical fields.

Use cases

loading an exported contact list into a fresh table without looping item by item.

Delete multiple rows

row.batchDelete

What you see in n8n

Notes & use cases

Removes up to 200 rows in one request, straight from their identifiers. The node looks nothing up first. Whatever feeds it has to know which rows it targets and where those identifiers came from.

Key parameters

Table Name or ID: the table the rows belong to, chosen from the dropdown or fixed by an expression.
Row IDs: the identifiers to remove, typed in one by one under defineBelow.
Property Containing Row ID: with autoMapInputData, the name of the property that carries the row ID inside each incoming item, so the list builds itself from the previous step.

Use cases

emptying a staging table once its rows have been copied somewhere durable.

Update multiple rows

row.batchUpdate

What you see in n8n

Notes & use cases

Applies a batch of edits in a single request, up to 200 rows. One call replaces the loop that would otherwise run the node once per incoming item, and a long sync feels it.

Key parameters

Rows: the collection filled with Add Row, where each entry carries the values to write under defineBelow.
Inputs to Ignore: properties that should not travel to Baserow under automatic mapping.
Table Name or ID: one table for the whole batch, so rows living in two tables need two nodes.

Use cases

writing a score or a status back onto the rows a previous step just computed.

Create a row

row.create

What you see in n8n

Notes & use cases

Adds one row to a table and returns it with the identifier Baserow assigns, which later nodes reuse to update or delete that same row.

Key parameters

Fields to Send: the column values, added one by one with Add Field when Data to Send is defineBelow.
Table Name or ID: a required field, so an empty value stops the node before it ever reaches Baserow.

Use cases

filing a support request as a row the moment the email arrives, ready for the rest of the branch.

Delete a row

row.delete

What you see in n8n

Notes & use cases

Deletes one row, and only that one, from the table you point at. The node expects the identifier, not the value of a column, so a name or an email address will not do.

Key parameters

Row ID: the identifier of the row to delete, typed in or carried over from a previous step through an expression.
Table Name or ID: the table that holds the row, since an identifier on its own does not say where to look.

Use cases

dropping a duplicate as soon as a check step flags it, one row per execution.

Get a row

row.get

What you see in n8n

Notes & use cases

Fetches a single row and hands its columns to the next node. Handy when a workflow holds an identifier and needs the content behind it.

Key parameters

Row ID: the identifier of the row to return, often the one a create step produced earlier in the same workflow.
Table Name or ID: the table to read, selected from the list or resolved by expression when a branch works across several tables.

Use cases

pulling the full record behind an identifier pasted in a message, before the branch decides what happens next.

Get many rows

row.getAll

What you see in n8n

Notes & use cases

Reads several rows in one call, with filtering, search and sort done on the Baserow side rather than in a Code node.

Key parameters

Table Name or ID: the table to read, chosen from the dropdown or fixed by an expression.
Return All: on, n8n walks the API pages until the last row; off, Limit caps how many rows come back.
Filters and Filter Type: comparison rules added with Add Filter; with two or more, AND requires them all and OR needs only one.
Search Term: text matched in any column; Sorting sets the row order.

Use cases

building a weekly digest from the rows added since the previous run.

Update a row

row.update

What you see in n8n

Notes & use cases

Rewrites the columns of one existing row. The row keeps its identifier, so the same workflow can come back to it further down the branch.

Key parameters

Table Name or ID: the table that holds the row, required alongside Row ID.
Row ID: the row that receives the new values.
Fields to Send: each column and its value, added with Add Field, or filled automatically under autoMapInputData.
Inputs to Ignore: the incoming properties to keep out of that automatic mapping.

Use cases

marking an order as shipped once the carrier confirms, without touching any other row.

Need help

Need help automating Baserow with n8n?

A person reads every message.

FAQ

Questions people ask about Baserow and n8n

01Is the Baserow n8n integration free?

Yes on the n8n side. The Baserow node ships with n8n, so there is nothing to install and nothing extra to pay for the connector itself, whether the workflow runs on n8n Cloud or on an instance you host yourself with Docker or npm. A workflow built on one runs identically on the other, which matters if you start on Cloud and move later. All 8 operations on the Row resource are available in both setups. What a Baserow plan costs on its own is a separate question, since it depends on the instance you point the credential at.

02Which credentials does the Baserow node need?

Two methods, and both start with the Host of your instance. Basic auth asks for the Username and Password of a Baserow user account, and the node then sees whatever that account can see. The token method asks for a Database Token created inside Baserow: log in, click the workspace in the top left corner, open its settings panel, then Database tokens, click Create token, and give the token a Name and a Workspace. Host stays on the default Baserow address for an instance hosted by Baserow, and becomes the API URL of your own instance when you host Baserow yourself. The credential is stored once in n8n and reused by every workflow.

03What are the limits of the Baserow node in n8n?

Three of them are worth planning around. The node works on one resource, Row, so anything about tables, fields or database structure stays out of reach and goes through the HTTP Request node, which calls any Baserow API endpoint with the same credential. Batch operations stop at 200 rows per request, so a bigger import becomes several calls. And reading many rows depends on Return All: left off, the node stops at the number set in Limit, which quietly truncates an export. Filters, Filter Type, Search Term and Sorting narrow the result before it reaches the workflow, which keeps executions lighter than filtering afterwards.

04Does Baserow trigger an n8n workflow in real time?

No, because Baserow has no trigger node in n8n. A workflow that touches Baserow starts somewhere else, and there are three usual doors. A Schedule Trigger runs it at a fixed interval, which fits a sync or a digest that reads rows with Get Many Rows. An n8n Webhook gives the workflow a URL that another service calls, so an external event opens the run and a row gets created in the same execution. Or the trigger of another tool starts everything, a new message or a new file, with Baserow sitting further down the branch as the destination.

05n8n or Make for Baserow?

It depends on where the data should sit and how you want to pay for the runs. n8n can be self-hosted with Docker or npm, so the rows and the credentials stay on infrastructure you control, and the same workflow also runs on n8n Cloud. Make is hosted only, with no self-hosting option, and its pricing counts operations, which stays predictable at small volumes and less so when a nightly job writes 200 rows at a time. Both build workflows visually. If your Baserow work loops over many rows, count the operations a Make scenario would consume before comparing the two on price.

Set the Host first

Log in with a user account

Or create a database token

Need help automating Baserow with n8n?