Build your own Zammad plugin

Searches for Zammad plugins often assume a marketplace like OTOBO or Znuny (.opm). Zammad does not ship one. In practice a “custom plugin” is an integration: you extend the helpdesk through admin features, webhooks, the REST API, or an external app — you do not install an .opm file.

This guide helps you pick the right path and ship something maintainable.

Four paths (decision table)

Path	When it fits	Upgrade risk	Typical result
Native integration	Slack, GitHub, GitLab, Teams, LDAP, CTI, Checkmk … already in core	low	Configure under Admin → Integrations
No-code in Zammad	Ticket-flow automation without another product	low	Triggers, schedulers, webhooks, core workflows, object manager
External app / API	Portal, ERP, n8n, MCP, monitoring, CMS	low–medium	A service that talks to `/api/v1`
Core patch / fork	UI or kernel behavior APIs and triggers cannot cover	high	Avoid unless you own the release process

Rule of thumb: try native and no-code first, then a thin API app. Fork the Zammad core only if you can carry merges, tests, and upgrades.

Path 1: Use native integrations

Many “Zammad Slack plugin” or “Zammad GitHub plugin” queries are already built in. Typical modules (see official admin docs):

Engineering: GitHub, GitLab — show issues on the ticket (GitLab: no merge requests)
Comms: Slack, Microsoft Teams, Telegram, SMS, social
Identity & sync: LDAP/Active Directory, Microsoft 365, Google, Exchange, Clearbit
Telephony: generic CTI, Placetel, Sipgate
Monitoring: Checkmk, Icinga, Nagios, Monit

Enable them under Admin → Integrations (admin.integration permission). Test on staging first; issue tokens with least privilege.

Directory of community and API packages: Zammad plugins.

Path 2: Webhooks, triggers, and the object manager

If your “plugin” should notify another system on ticket changes, you usually do not need Ruby.

Create an endpoint under Admin → Webhooks (generic or a template for Slack, Teams, Mattermost, Rocket.Chat, ntfy).
Configure a trigger or scheduler to invoke that webhook.
On the receiver, inspect:
- X-Zammad-Trigger — trigger name
- X-Zammad-Delivery — unique delivery id (idempotency)
- X-Hub-Signature — HMAC-SHA1 if you set a signature token
- User-Agent: Zammad User Agent

Core workflows cover conditional fields and visibility. The object manager (UI or POST /api/v1/object) adds custom fields on ticket, user, or organization — often enough for domain data without core code.

Official starters: Add webhooks, Webhook payload.

Path 3: Your plugin as a REST API integration

This is the default for a custom Zammad plugin: a service (Python, Node, PHP, n8n, MCP) that uses the Zammad REST API.

Authentication

Zammad supports three methods. Prefer access tokens for integrations; avoid basic auth.

bash

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

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

Users create tokens in personal preferences. Scope permissions as tightly as possible.

Create a ticket (example)

bash

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

The same pattern fits portals, checkout, forms, or monitoring callbacks. Ready-made clients in the hub: zammad_py, zammad-api-client-php, laravel-zammad.

Automation layer instead of a core plugin

If you orchestrate workflows (ERP ↔ Zammad, Entra ID sync, AI drafts), keep logic outside Zammad:

n8n-nodes-zammad / n8n-nodes-zammad-extended
zammad-mcp-server for agents in Claude, Cursor, and similar tools

Zammad upgrades then stay independent of your plugin logic.

Path 4: Changing the Zammad core

Zammad is AGPL-3.0 (Ruby on Rails, modern Vue frontend). You can fork the source. That is not a plugin marketplace:

Every upgrade must re-merge your patches.
Frontend and API contracts change across majors (for example Zammad 6 → 7).
Hosted offerings (Zammad Cloud) typically reject kernel patches.

To contribute upstream, follow the official contributing docs — that is core development, not a private add-on format.

Go-live checklist

Staging instance with a production-like data model
Least-privilege tokens and documented rotation
Verify webhook signatures; handle retries and X-Zammad-Delivery
Personal ticket data: processing agreements, storage location, logs
Re-test after Zammad minor updates (API fields, integrations)
README: required Zammad version, permissions, sample payloads

List it on Open ITSM Hub

Community integrations often live only as GitHub repos. Add your project to the package directory so admins can find “Zammad plugins” in one place. For OTOBO/Znuny packages see Publish a package.