Zammad Api Client Php Laravel Package

Product Decisions This Supports

• Build vs. buy for support tooling: Use Zammad as the helpdesk system of record and this client as the PHP integration layer, instead of building ticket, agent, SLA, and notification infrastructure in-house. For a Laravel product team, this can reduce a multi-week custom API integration to days.
• Roadmap prioritization: Shift engineering effort from “build a helpdesk” to “embed support where customers already are.” The package enables in-product ticket creation, ticket lookup, article/attachment retrieval, tagging, ticket linking, and user/org sync, so the roadmap can focus on contextual support workflows rather than agent-console features.
• Feature decisions: Supports features such as “create a support ticket from an order/account screen,” “show recent tickets to customers or agents,” “sync Laravel users/organizations into Zammad,” “auto-tag tickets by product area,” “link related tickets,” and “attach generated PDFs/logs to tickets.”
• Use-case validation: Strong fit for SaaS customer support, ecommerce post-purchase support, internal IT/helpdesk, agency client support, and any Laravel app that needs Zammad-backed ticketing without exposing Zammad directly to customers.
• Integration architecture decision: Adopt a thin Laravel adapter around this package rather than coupling domain code directly to it. This allows the team to swap clients, mock in tests, and contain the impact of v2→v3 changes.
• Version strategy: For greenfield work, evaluate the v3 release candidate for typed DTOs, PSR-18 HTTP client, typed exceptions, and PHP 8.1+ support. For conservative production use, pin the stable v2 line unless v3 RC has been validated in staging.

When to Consider This Package

• Consider it when Zammad is already chosen or strongly favored and the product is PHP/Laravel-based. The package covers the common resource operations: tickets, articles, states, tags, links, attachments, search, pagination, CSV import, and on-behalf-of-user calls.
• Consider it when the team needs time-to-market over bespoke infrastructure, has a small platform team, and is comfortable relying on Zammad for agent workflows, SLAs, and omnichannel handling.
• Consider it when the required integration is primarily server-side CRUD and search. The README shows a straightforward resource model, but the package does not validate Zammad fields, so the product should not assume schema safety without its own validation layer.
• Consider the v3 RC when the team is on PHP 8.1+, wants typed exceptions/DTOs, and can run integration tests against a staging Zammad instance. Consider v2 when production stability and existing examples matter more than modern typing.
• Look elsewhere or build a custom client when:
  • The stack is not PHP/Laravel.
  • Legal cannot accept the NOASSERTION license without clarification.
  • The team requires a vendor-backed SLA, high ecosystem adoption, or a stable typed SDK today.
  • The product needs deep real-time behavior, advanced webhook orchestration, or custom object-schema validation beyond what the client exposes.
  • The organization is not using Zammad and has no appetite to operate it.
  • The integration is high-volume or business-critical enough that 64 stars and 0 dependents represent unacceptable maintenance/community risk without an internal ownership plan.
• Treat the package as infrastructure glue, not a platform bet. The strategic bet is on Zammad; the package is replaceable with a custom HTTP wrapper if maintenance or licensing becomes a problem.

How to Pitch It (Stakeholders)

• Executive summary: We can add integrated customer support workflows to our Laravel product faster by using Zammad as the helpdesk backend and this PHP client as the integration layer. This avoids building ticket, agent, SLA, and notification systems ourselves, while keeping customers inside our product and agents inside a proven helpdesk UI.
• Product value: The package enables contextual support—tickets created from orders/accounts, recent-ticket visibility, attachments, tags, and ticket linking—without making Zammad the customer-facing experience. That supports differentiation through product context rather than commodity helpdesk features.
• Engineering value: It provides a Composer-installable client with resource CRUD, search, pagination, tags, links, attachments, CSV import, and on-behalf-of-user support. The v3 RC adds typed DTOs, PSR-18, and typed exceptions. We should wrap it behind a Laravel service/interface, pin versions, and test against staging Zammad.
• Risk and mitigation: Adoption is low and the license is marked NOASSERTION, so legal review and an internal ownership plan are required. Mitigate by isolating the client behind an adapter, adding integration tests, monitoring upstream releases, and retaining the option to replace it with a small custom client.
• Recommendation: Proceed with a time-boxed spike if Zammad is already the preferred helpdesk. Validate v3 RC versus v2, confirm license terms, and estimate the thin Laravel adapter. If the spike passes, adopt; if not, keep Zammad but build a minimal internal client.