Skip to main content

Emission and delivery

Where events come from#

ActivityEventsWhich functions run
Creating or updating a site userPRE_USER_CREATE, POST_USER_CREATE, POST_USER_UPDATEEvery subscribed function in the site
Deleting a site userPOST_USER_DELETEEvery subscribed function in the site
Creating, updating, or deleting data table recordsRECORD_CREATE, RECORD_UPDATE, RECORD_DELETESubscribed functions in the same app as the table

RECORD_CREATE fires for POST …/data/, RECORD_UPDATE for PATCH …/data/ and PATCH …/data/ID/, and RECORD_DELETE only for a single-record DELETE …/data/ID/. Upserts and bulk or filtered deletes don't fire record events.

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 put the user's fields under data, so read params["data"]["email"]:
    • PRE_USER_CREATE: type and data, which includes the submitted plaintext password.
    • POST_USER_CREATE: type and data.
    • POST_USER_UPDATE: type, user_id, data, previous_data, and changed_fields.
    • POST_USER_DELETE: type, data, and deleted_by.
  • Record events include type, app_slug, datatable, data (the record), and record_id (the record's primary key). RECORD_UPDATE also includes previous_data.

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 — no run or record is created;
  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 an object of user fields, such as {"first_name": "Ada"}, to change the values that are saved. Only existing user fields with non-null values are applied;
  • fail or time out, which cancels the user creation.

A subscribed PRE_USER_CREATE function that is inactive also cancels every user creation, so unsubscribe a function before you deactivate it.

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.