Events security and limits
Who can do what#
| Operation | Who can do it |
|---|---|
| List event names | Any signed-in caller |
| Subscribe and unsubscribe functions | Organization owners and admins, and other cloud users with access to the site |
| List an app's subscribers | Same as subscribe |
Site users — the people who sign in to your application — get 403 for
subscription changes, even in apps they use.
Scope#
Subscriptions and functions belong to one site; events never cross sites. Within a site, record events only run functions in the table's app, while user events run every subscribed function. Use filter conditions to narrow which runs happen.
Sensitive data in payloads#
Event payloads can contain personal data, record contents, and — for
PRE_USER_CREATE — the submitted password. Treat payloads as sensitive: don't
log them in full or store passwords.
Limits#
| Topic | Behavior |
|---|---|
| Event types | Seven fixed event names |
| Duplicate subscriptions | Rejected |
| How functions run | In the background, except PRE_USER_CREATE, which blocks user creation |
PRE_USER_CREATE wait | Up to 30 seconds per function |
| Events with no subscribers | Nothing runs; no error |
| One function fails | Other subscribed functions still run |
| Failed runs | Not retried |
| Filter conditions don't match | The function is skipped; no run or record is created |
You can't define custom events or publish events through the API, and the SDKs don't include Events methods.
If you see an event run a function in another app or site, report it to TaruviBase support as a security issue.