Eigenes Zammad Plugin entwickeln

Wer nach Zammad Plugins sucht, erwartet oft einen Marketplace wie bei OTOBO oder Znuny (.opm). Den gibt es bei Zammad nicht. Ein „eigenes Plugin“ ist in der Praxis eine Integration: Sie erweitern das Helpdesk über Admin-Funktionen, Webhooks, die REST-API oder eine externe App — ohne eine .opm-Datei ins System zu laden.

Diese Anleitung hilft Ihnen, den richtigen Weg zu wählen und eine wartbare Erweiterung zu bauen.

Die vier Wege (Entscheidungshilfe)

Weg	Wann sinnvoll	Update-Risiko	Typisches Ergebnis
Native Integration	Slack, GitHub, GitLab, Teams, LDAP, CTI, Checkmk … bereits im Kern	niedrig	Konfiguration unter Admin → Integrationen
No-Code in Zammad	Automatisierung im Ticketfluss ohne fremdes System	niedrig	Trigger, Scheduler, Webhooks, Core Workflows, Objektmanager
Externe App / API	Eigenes Portal, ERP, n8n, MCP, Monitoring, CMS	niedrig–mittel	Service, der `/api/v1` spricht
Core-Patch / Fork	UI- oder Kernverhalten, das API und Trigger nicht abdecken	hoch	Gemiedene Variante, nur mit eigenem Release-Prozess

Faustregel: Erst nativ und No-Code prüfen. Dann eine schlanke API-App. Den Zammad-Kern nur forken, wenn Sie Updates, Tests und Merge-Konflikte wirklich tragen können.

Weg 1: Native Integrationen nutzen

Viele Suchanfragen nach „Zammad Slack Plugin“ oder „Zammad GitHub Plugin“ sind bereits eingebaut. Typische Module (Stand der offiziellen Admin-Dokumentation):

Entwicklung: GitHub, GitLab — Issues im Ticket sichtbar machen (GitLab: keine Merge Requests)
Kommunikation: Slack, Microsoft Teams, Telegram, SMS, Social
Identität & Sync: LDAP/Active Directory, Microsoft 365, Google, Exchange, Clearbit
Telefonie: generisches CTI, Placetel, Sipgate
Monitoring: Checkmk, Icinga, Nagios, Monit

Aktivierung unter Admin → Integrationen (Berechtigung admin.integration). Zuerst auf einer Staging-Instanz testen, Tokens mit Minimalrechten ausstellen.

Verzeichnis aller Community- und API-Pakete: Zammad Plugins.

Weg 2: Webhooks, Trigger und Objektmanager

Für ein „Plugin“, das bei Ticketänderungen ein anderes System benachrichtigt, brauchen Sie meist keinen Ruby-Code.

Unter Admin → Webhooks einen Endpoint anlegen (generisch oder Vorlage für Slack, Teams, Mattermost, Rocket.Chat, ntfy).
Einen Trigger oder Scheduler so konfigurieren, dass er diesen Webhook auslöst.
Am Empfänger die Header prüfen:
- X-Zammad-Trigger — Name des Triggers
- X-Zammad-Delivery — eindeutige Delivery-ID (Idempotenz)
- X-Hub-Signature — HMAC-SHA1, wenn Sie ein Signature-Token gesetzt haben
- User-Agent: Zammad User Agent

Zusätzlich decken Core Workflows bedingte Felder und Sichtbarkeit ab. Der Objektmanager (UI oder API POST /api/v1/object) legt Custom Fields an Ticket, User oder Organisation an — oft die Basis für fachliche „Plugin“-Daten, ohne Kerncode.

Offizielle Einstiege: Webhooks hinzufügen, Webhook-Payload.

Weg 3: Eigenes Plugin als REST-API-Integration

Das ist der Standardweg für ein eigenes Zammad Plugin: ein Dienst (Python, Node, PHP, n8n, MCP), der die Zammad REST API nutzt.

Authentifizierung

Zammad unterstützt drei Verfahren. Access Tokens sind der Default für Integrationen; Basic Auth nur im Notfall.

bash

# HTTP Token (empfohlen)
curl -H "Authorization: Token token=IHR_TOKEN" \
  https://helpdesk.example.com/api/v1/users/me

# OAuth2 Bearer
curl -H "Authorization: Bearer IHR_TOKEN" \
  https://helpdesk.example.com/api/v1/users/me

Tokens legt der Benutzer unter den persönlichen Einstellungen an. Rechte so eng wie möglich (nur benötigte Ticket-/User-Scopes).

Ticket anlegen (Beispiel)

bash

curl -X POST https://helpdesk.example.com/api/v1/tickets \
  -H "Authorization: Token token=IHR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Monitoring: CPU > 90%",
    "group": "Users",
    "customer": "monitoring@example.com",
    "article": {
      "subject": "Alert",
      "body": "Host server-01 überschreitet den Schwellwert.",
      "type": "note",
      "internal": true
    }
  }'

Dasselbe Muster eignet sich für Portale, Shop-Checkout, Formulare oder Monitoring-Callbacks. Fertige Clients im Hub: zammad_py, zammad-api-client-php, laravel-zammad.

Automation-Layer statt Kern-Plugin

Wenn Sie Workflows orchestrieren wollen (ERP ↔ Zammad, Entra-ID-Sync, KI-Entwürfe), lagern Sie die Logik außerhalb von Zammad:

n8n-nodes-zammad / n8n-nodes-zammad-extended
zammad-mcp-server für Agenten in Claude, Cursor & Co.

Vorteil: Zammad-Upgrades bleiben unabhängig von Ihrer Plugin-Logik.

Weg 4: Änderungen am Zammad-Kern

Zammad ist AGPL-3.0 (Ruby on Rails, modernes Vue-Frontend). Sie können den Quellcode forken. Das ist kein Plugin-Marktplatz:

Jedes Upgrade muss Ihre Patches neu mergen.
Frontend- und API-Verträge ändern sich zwischen Major-Versionen (z. B. Zammad 6 → 7).
Hosting-Anbieter (Zammad Cloud) lassen Kernel-Patches in der Regel nicht zu.

Wenn Sie beitragen wollen, folgen Sie der offiziellen Contributing-Doku — das ist Upstream-Entwicklung, kein privates Addon-Format.

Checkliste vor dem Go-live

Staging-Instanz mit produktionsnahem Datenmodell
Token mit Least Privilege, Rotation dokumentiert
Webhook-Signatur prüfen, Retries und X-Zammad-Delivery behandeln
Personenbezogene Ticketinhalte: Auftragsverarbeitung, Speicherort, Logs
Verhalten nach Zammad-Minor-Updates testen (API-Felder, Integrationen)
README: benötigte Zammad-Version, Rechte, Beispiel-Payloads

Im Open ITSM Hub listen

Community-Integrationen sind oft nur als GitHub-Repo sichtbar. Tragen Sie Ihr Projekt ins Paketverzeichnis ein, damit Admins „Zammad Plugins“ zentral finden. Analog für OTOBO/Znuny: Paket veröffentlichen.