DE Skip to documentation

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
<?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.