Developers
Hooks and webhooks
Extend the Symfony application deliberately; understand which webhook features do not exist yet.
On this page
Current extension points
Care CMS is a Symfony application. Developers can extend it through services, dependency injection, controllers, Doctrine entities, Twig extensions and Symfony event subscribers. There is no WordPress-style public actions/filters API or plugin ZIP installer. Application services use autowiring and autoconfiguration. Existing subscribers handle request/response security headers, administrator session checks, content conflicts, login audit events and EasyAdmin lifecycle events.
Example response subscriber
This example adds a harmless response header in developer-owned source. It is not code to paste into a page, AI module or shared layout.
<?php
namespace App\EventSubscriber;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpKernel\Event\ResponseEvent;
use Symfony\Component\HttpKernel\KernelEvents;
final class PracticeResponseSubscriber implements EventSubscriberInterface
{
public static function getSubscribedEvents(): array
{
return [KernelEvents::RESPONSE => 'onResponse'];
}
public function onResponse(ResponseEvent $event): void
{
if (!$event->isMainRequest()) return;
$event->getResponse()->headers->set('X-Practice-Theme', 'custom');
}
}Webhook availability
The current build has no public webhook registration/list/update/delete API, outgoing publish webhook settings or signing-secret management screen. Do not use Contentstack API examples against Care CMS; those endpoints belong to a different product. The optional Google exports use their own reviewed queue and provider adapters. They are not a generic arbitrary-destination webhook service.
Requirements for a future connector
- Fixed event names and a minimal, documented payload with no private content by default.
- Verified destinations and protection against private-network/metadata endpoint requests.
- Signed messages, timestamp/replay checks, bounded retries, idempotency and delivery history.
- Administrator permissions, CSRF, encrypted secrets and a clear revoke/disable workflow.
- Tests for duplicate delivery, failures, consent and data-retention boundaries.
These are design requirements for future development, not features currently available from the dashboard.
Something unclear? Contact me about this guide.