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 run is recorded as skipped |
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.