Event Hooks
Event Hooks are disabled in current builds. The screen is hidden from the menu and both the read and save operations refuse with “Event hooks are temporarily disabled”, so nothing on this page can be configured today. To react to configuration changes now, use System Webhooks, which are available and deliver a JSON payload to a URL of your choosing.
Event Hooks let you run an external command (typically a shell script) whenever the Configuration Manager creates, modifies, or deletes a Tenant or a User Extension. They are a way to keep an outside system - a billing platform, a CRM, a provisioning script, or a directory - in step with changes made in the Manager, without polling the database or writing a custom integration against it.
The difference between the two mechanisms is where your code runs: an event hook runs a command on the management server itself, while a system webhook sends an HTTP request to a service you host anywhere.
How it works
Each object type has a set of lifecycle stages, and you assign a command to any stage you care about. When the object reaches that stage, the Manager runs your command on the management server.
- Command to execute Before Creation - runs just before the object is created.
- Command to execute After Creation - runs after the object has been created.
- Command to execute Before Modification - runs just before changes are saved.
- Command to execute After Modification - runs after changes are saved.
- Command to execute Before Deletion - runs just before the object is deleted.
You configure these separately for Tenants and for User Extensions. Leave a field blank to take no action at that stage.
What the command receives
Information about the object that triggered the event is passed to your command in environment variables, so your script can read the object’s attributes directly. In addition, the key of the managed object is passed as a command-line argument; on a multi-tenant system the tenant is passed as an argument as well. A before hook fires while the change is still pending, which is the right place to validate or reserve resources externally; an after hook fires once the change is committed, which is the right place to notify downstream systems.
Best practices
- Keep hooks fast and non-blocking. The command runs as part of the save operation, so a slow script delays the admin action. For anything that can be slow (network calls, remote APIs), have the hook drop a job on a queue and return immediately.
- Make scripts idempotent and defensive. Handle missing variables gracefully and do not assume a field is always populated.
- Log inside your script so you can trace what fired and when; the Manager does not surface command output in the UI.
- Test before relying on it. Point a hook at a script that just logs its environment variables and arguments, trigger the event once, and confirm the payload matches what your integration expects.
- Mind permissions. The command runs with the privileges of the management service - secure any scripts and credentials it touches accordingly.