Self-hosted
When I turn in 2FA in self-hosted baserow I get the following error in the n8n baserow node. Turning it off solves it.
{ “error”: “ERROR_INVALID_CREDENTIALS”, “detail”: “No active account found with the given credentials.” }
Maybe I’m doing something wrong, in that case node documentation need updating?
Hey @contentpeter, I’m afraid the current Baserow n8n node is not compatible with the 2FA in Baserow. This is because it uses the email+password authentication, and that one now requires a 2FA token.
We’ve made efforts to update the Baserow n8n node here: Baserow node update batch operations, additional filters, and token auth by bram2w · Pull Request #19758 · n8n-io/n8n · GitHub, but n8n would need to do a final review and merge the changes in their codebase. Once that it merged, it will be possible to provide a database token, which doesn’t need the 2FA step.
It would be great if you can respond to that pull request and ask them what the state is, explaining the situation with the 2FA. It might help to get it through faster.
Hey @bram , thanks for the context on the n8n situation.
I’m currently building the equivalent Baserow piece for Activepieces and ran into the same 2FA limitation. We’ve implemented a dual-auth approach — Database Token for actions, and Email & Password (JWT) for triggers with automatic webhook registration via the /api/database/webhooks/ endpoints.
The database token solution works well for CRUD actions, but it doesn’t solve the trigger problem: the webhook management API requires JWT auth, so database token users can’t get automatic webhook registration. They’re stuck with manual webhook setup, which is a poor UX.
For users who require 2FA, the database token fallback keeps actions working, but their trigger experience remains limited. The real bottleneck is that Baserow’s webhook management endpoints don’t accept database tokens — if they did, the 2FA issue would disappear entirely for automation platforms.
Is there any plan on the Baserow side to either:
Allow database tokens to manage webhooks, or
Provide an API token type that bypasses 2FA while still having full API access (like a personal access token)?
Either would unblock seamless trigger support for all users across n8n, Activepieces, and other integration platforms.
Hey @bastien, thanks for the feedback and for building an equivalent for Activepieces. That’s really cool! It’s a bit of a tricky scenario because providing an API token that bypasses the 2FA would defeat the purpose of the 2FA, so that’s definitely not something we would do.
I like the idea of allowing a database token to create webhooks, although we would carefully need to consider the security purposes there as well because we should only allow creating webhooks if the token explicitly allows, and if the token has read permissions to that table. The creation of the token should then be limited to rows and view related webhook events. Would something like that work for you?
At the moment there are so many high priority tasks that the dev team must work on that I can’t make any promises on when this would be implemented. But I’m happy to create a GitHub issue if that makes sense.
Hey @bram, yes, that scoped approach would work perfectly for our use case — limiting webhook creation to tables the token can already read, restricted to row/view events, is exactly what’s needed for end-to-end trigger support.
Please do open a GitHub issue and share the link here so I can follow it and add context from the Activepieces side if useful. Thanks for considering it!
Of course! Here you go: Create row webhooks using database tokens · Issue #5131 · baserow/baserow · GitHub