Am I missing the value of the view-related webhooks?

Are you using our SaaS platform (Baserow.io) or self-hosting Baserow?

Self-hosted

What do you need help with?

I’m confused about how the view-related webhooks work. It looks like they trigger when the view itself is created or updated or deleted, which is of such little value that I spent an hour this morning testing them, convinced I was mistaken.

The whole point of views is to have a slice of data, and it makes sense to trigger events when data within the view is updated/added/removed, such as having a record appear within the view because it’s ready for some action to be taken on it. Airtable supports this.

Is Baserow’s implementation really just supposed to fire every time someone changes a filter or adds a sort? (Also, I can’t get it to fire at all, no matter what I do with the view.)

Hey @monachus

Is Baserow’s implementation really just supposed to fire every time someone changes a filter or adds a sort?

No, it’s supposed to call the webhook every time something happens to the view or the data in the table, such that one or more rows that weren’t visible in the view before become visible.

I just tested both on our SaaS and locally and it’s working as expected. When a row enters the view, the webhook is called with a payload with the same structure of the one shown in the example in the modal.

Which tests have you done? Are you sure the celery-export-worker process is running and processing tasks?