Emission and delivery

Where events come from

Activity	Events	Which functions run
Creating or updating a site user	PRE_USER_CREATE, POST_USER_CREATE, POST_USER_UPDATE	Every subscribed function in the site
Deleting a site user	POST_USER_DELETE	Every subscribed function in the site
Creating, updating, or deleting data table records	RECORD_CREATE, RECORD_UPDATE, RECORD_DELETE	Subscribed functions in the same app as the table

If running a subscribed function fails, the original request — for example, creating the record — still succeeds.

What your function receives

Your function's params contain the event payload:

• User events include type and the user's fields. PRE_USER_CREATE also includes the submitted password. POST_USER_UPDATE includes user_id, data, previous_data, and changed_fields.
• Record events include type, app_slug, datatable, data (the record), and record_id (the record's primary key).

Creating several records in one request sends one RECORD_CREATE per record.

How delivery works

When an event fires, TaruviBase:

1. finds the functions subscribed to it;
2. for record events, keeps only functions in the table's app;
3. skips any function whose filter conditions don't match the payload — the run is recorded as skipped;
4. runs each remaining function in the background.

If one function fails, the others still run. Failed runs aren't retried. An event with no subscribers does nothing.

Blocking user creation

PRE_USER_CREATE runs before the user is created, and user creation waits for it — up to 30 seconds per subscribed function. Your function can:

• return {"result": {...}} with user fields to change the values that are saved;
• fail or time out, which cancels the user creation.

Every other event runs after the change is saved and doesn't delay it.

Limitations

• You can't define custom event names or publish events over the API.
• Delivery isn't guaranteed and failed runs aren't retried. Design functions to be safe to run again, and monitor their runs.