Triggers and Extensibility

Endpoint triggers run around the selected database operation inside the operation transaction.

{
  type: "PUT",
  admin: ALL,
  editor: { allowed: ["title", "status"], disallowed: [] },
  triggers: [
    { type: "BEFORE", /* trigger condition/action */ },
    { type: "AFTER",  /* trigger condition/action */ }
  ]
}

Before triggers

Before triggers can transform the data used by the main operation or execute configured logic before it runs.

After triggers

For updates and deletes, the engine can capture values before execution; mutation results and post-operation values may be made available to trigger logic. After triggers then run in the same transaction.

Execution order

1. Resolve request and policy.
2. Open transaction.
3. Run BEFORE triggers.
4. Run the main operation.
5. Run AFTER triggers.
6. Commit or roll back.

disable_triggers: true in build options disables trigger execution.

Safe patterns

• Keep trigger functions deterministic when possible.
• Avoid unbounded recursion: nested trigger queries are built with triggers disabled by the trigger runner.
• Treat user-defined functions as privileged application code.
• Keep external side effects out of a database transaction unless they are idempotent and coordinated.
• Test rollback behavior for trigger failures.

Caution

Trigger configuration is powerful and its exported type combines several action shapes. Until the API stabilizes, use repository examples and tests as the executable source of truth.

← Validation & Workflows · Recipes →