Send a webhook for every change a person makes to a record

Events are {resource}.created, .updated, .deleted and .restored for content,
the inbox, redirects, repositories and media, taken from the audit log so the
two agree on what happened. Subscriptions take wildcards. Users, tokens,
webhooks and settings are never sent, nor what the application does by
itself; the inbox's own words only with personal data enabled.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

README.md

@@ -1472,7 +1472,21 @@ POST   /api/v1/webhook-deliveries/{id}/redeliver
 ```
 
 Avisan a otro sistema de `application.received`, `content.published`,
-`content.unpublished`, `review.requested` y `review.returned` (o `*`). Salen de
+`content.unpublished`, `review.requested` y `review.returned`, y además de
+**cualquier cambio que haga una persona en una ficha**: `{tipo}.created`,
+`.updated`, `.deleted` y `.restored` para páginas, categorías, etiquetas,
+proyectos, miembros, servicios, clientes, testimonios, charlas, tecnologías,
+convocatorias, redirecciones, repositorios, medios y el buzón. Se puede
+suscribir a uno, a `*`, a todo un tipo (`projects.*`) o a una acción en
+cualquiera (`*.deleted`).
+
+Esos eventos salen del [registro de auditoría](#registro-de-auditoría), así
+que dicen lo mismo que él —qué ficha, quién, por dónde (panel, API, token) y,
+al editar, qué campos cambiaron con su valor anterior y el nuevo— y dejan fuera
+lo mismo: lo que hace la aplicación sola y los secretos. Del buzón solo se
+cuenta cómo se está atendiendo, salvo con `include_personal_data`. Usuarios,
+tokens, webhooks y ajustes no se envían nunca: son la seguridad de la
+aplicación, no su contenido. Salen de
 los propios registros —el historial ya distingue publicar de editar, venga del
 panel, de la API o de un lote— y no de los controladores, así que no hay forma
 de publicar algo sin que se avise.