Skip to main content
Collection Hooks are Hooks that run on Documents within a specific Collection. They allow you to execute your own logic during specific events of the Document lifecycle. To add Hooks to a Collection, use the hooks property in your Collection Config:
You can also set hooks on the field-level to isolate hook logic to specific fields. More details.

Config Options

All Collection Hooks accept an array of synchronous or asynchronous functions. Each Collection Hook receives specific arguments based on its own type, and has the ability to modify specific outputs.

beforeOperation

The beforeOperation hook can be used to modify the arguments that operations accept or execute side-effects that run before an operation begins.
The following arguments are provided to the beforeOperation hook:

beforeValidate

Runs during the create and update operations. This hook allows you to add or format data before the incoming data is validated server-side. Please do note that this does not run before client-side validation. If you render a custom field component in your front-end and provide it with a validate function, the order that validations will run in is:
  1. validate runs on the client
  2. if successful, beforeValidate runs on the server
  3. validate runs on the server
The following arguments are provided to the beforeValidate hook: Why isn’t id in data? data only represents the delta you’re saving. Read originalDoc.id during updates, and prefer afterChange if you need the id during creates
On update operations, data contains only the fields being changed. It may omit id and any unchanged fields. Use originalDoc to read existing values. On create, data is the new submission and the document id is not yet available at this stage.

beforeChange

Immediately before validation, beforeChange hooks will run during create and update operations. At this stage, the data should be treated as unvalidated user input. There is no guarantee that required fields exist or that fields are in the correct format. As such, using this data for side effects requires manual validation. You can optionally modify the shape of the data to be saved.
The following arguments are provided to the beforeChange hook: Why isn’t id in data? data only represents the delta you’re saving. Read originalDoc.id during updates, and prefer afterChange if you need the id during creates
On update operations, data contains only the fields being changed. It may omit id and any unchanged fields. Use originalDoc to read existing values. On create, data is the new submission and the document id is not yet available at this stage.

afterChange

After a document is created or updated, the afterChange hook runs. This hook is helpful for recalculating statistics, syncing user profile changes to a CRM, and more.
The following arguments are provided to the afterChange hook:

beforeRead

Runs before find and findByID operations are transformed for output by afterRead. This hook fires before hidden fields are removed and before localized fields are flattened into the requested locale. Using this Hook will provide you with all locales and all hidden fields via the doc argument.
The following arguments are provided to the beforeRead hook:

afterRead

Runs as the last step before documents are returned. Flattens locales, hides protected fields, and removes fields that users do not have access to.
The following arguments are provided to the afterRead hook:

beforeDelete

Runs before the delete operation. Returned values are discarded.
The following arguments are provided to the beforeDelete hook:

afterDelete

Runs immediately after the delete operation removes records from the database. Returned values are discarded.
The following arguments are provided to the afterDelete hook:

afterOperation

The afterOperation hook can be used to modify the result of operations or execute side-effects that run after an operation has completed.
The following arguments are provided to the afterOperation hook:

afterError

The afterError Hook is triggered when an error occurs in the FrogBot application. This can be useful for logging errors to a third-party service, sending an email to the development team, logging the error to Sentry or DataDog, etc. The output can be used to transform the result object / status code.
The following arguments are provided to the afterError Hook:

beforeLogin

For Auth-enabled Collections, this hook runs during login operations where a user with the provided credentials exist, but before a token is generated and added to the response. You can optionally modify the user that is returned, or throw an error in order to deny the login operation.
The following arguments are provided to the beforeLogin hook:

afterLogin

For Auth-enabled Collections, this hook runs after successful login operations. You can optionally modify the user that is returned.
The following arguments are provided to the afterLogin hook:

afterLogout

For Auth-enabled Collections, this hook runs after logout operations.
The following arguments are provided to the afterLogout hook:

afterMe

For Auth-enabled Collections, this hook runs after me operations.
The following arguments are provided to the afterMe hook:

afterRefresh

For Auth-enabled Collections, this hook runs after refresh operations.
The following arguments are provided to the afterRefresh hook:

afterForgotPassword

For Auth-enabled Collections, this hook runs after successful forgotPassword operations. Returned values are discarded.
The following arguments are provided to the afterForgotPassword hook:

refresh

For Auth-enabled Collections, this hook allows you to optionally replace the default behavior of the refresh operation with your own. If you optionally return a value from your hook, the operation will not perform its own logic and continue.
The following arguments are provided to the refresh hook:

me

For Auth-enabled Collections, this hook allows you to optionally replace the default behavior of the me operation with your own. If you optionally return a value from your hook, the operation will not perform its own logic and continue.
The following arguments are provided to the me hook:

TypeScript

FrogBot exports a type for each Collection hook which can be accessed as follows:
You can also pass a generic type to each hook for strongly-typed doc, previousDoc, and data properties: