Internal hooks are compiled product components
The account adapter has a versioned registry of compiled hooks. Each captured operation stores an immutable hook manifest {name, version, input}. Recovery reuses that manifest rather than recalculating against mutable live state. Duplicate/unknown versions or malformed input fail verification. This is an internal Go contract, not a public webhook URL or a folder where Customers upload PHP scripts.
Every registered lifecycle family
| Hook name | Component responsibility |
|---|---|
dns.authoritative |
Account-owned authoritative DNS activation/lifecycle. |
databases.activation |
Account database service activation/blocking. |
mail.activation |
Account mail activation/blocking. |
websites.hosting |
Managed website service/routes during account lifecycle. |
certificates.activation |
Managed certificate activation during account lifecycle. |
applications.runtime |
Application services, schedules and account application-access policy. |
transfers.access |
Scoped transfer-user access during account lifecycle. |
applications.website-termination |
Website-dependent application termination/recovery. |
certificates.website-termination |
Website-dependent certificate withdrawal/termination. |
databases.website-termination |
Website database-binding lifecycle; does not mean arbitrary database data deletion. |
Phase contract
Account hooks expose name/version, impact, plan, apply, commit, inspect and compensate. Stateful hooks can acknowledge retained native receipts after metadata publication. The adapter preserves operation ID, generation, parent account/revision, desired/previous state, hook input and receipt across replay. Commit, compensation, metadata publication and acknowledgement are distinct boundaries; a successful native call cannot be relabeled a complete job.
The newer application preparation hook version 2 has action-selective prepare/inspect-preparation/seal/compensate-preparation behavior and persisted binding digests. It does not silently reinterpret old version-1 journals. Unsupported access/WordPress preparation needs its own proof.
Reactivation dependency order
The compiled graph brings DNS before mail; databases and mail before websites; websites before applications and certificates; databases and mail before applications. Only present hook dependencies participate, with deterministic ordering. Other actions use their reviewed captured order. Ordering establishes prerequisites, not live route health or complete recovery.
Operational consequences
Account suspension/reactivation/termination may wait for multiple modules. Inspect exact durable events and module effects; do not remove one failing hook, reorder persisted manifests, clear receipts or force SQL state to finish. Failure can legitimately retain resource/name fences until qualified compensation. Full reconstruction is still required for destructive lifecycle/update acceptance. These hooks provide no external billing create callback or arbitrary command execution.