Statamic Secretary Laravel Package

Product Decisions This Supports

• Feature scoping for email operations inside the CMS. The package puts Postmark handling behind a Control Panel surface, and v0.1.11+ adds replay protection. If our ops/support teams need to see Postmark events or resend/replay webhooks without leaving Statamic, this is a candidate feature rather than a custom build.
• Build vs. buy for webhook idempotency. Replay protection is exactly the kind of fiddly, security-adjacent logic we would otherwise hand-roll. Paying the integration cost here is cheaper than owning replay-window, signature, and dedupe logic in-house — provided we accept pre-1.0 API risk.
• Security and compliance sign-off. v0.1.13 is a hardening release: committed Control Panel assets rebuilt against a pinned Statamic 6.31.0 lock, plus deterministic frontend asset verification in CI. That gives us a reproducible-build story and a clean answer to "how do you know the shipped JS matches source?" — useful for vendor review, SBOM, and supply-chain questionnaires.
• Upgrade/roadmap planning. The pin to Statamic 6.31.0 sets a minimum platform baseline. That is a real roadmap constraint: adopting this package couples our Statamic upgrade cadence to the maintainer's release cadence.
• Not supported by this release: no new user-facing capability, no deprecations, no breaking changes. v0.1.13 does not change the product calculus — it improves the trust story around an already-scoped decision.

When to Consider This Package

Adopt (pilot) when:

• We are on Statamic 6.31.0 or later and on a supported Laravel/PHP matrix; the pinned dev lock implies the maintainer builds against that baseline, so older Statamic versions are a compatibility question, not an assumption.
• The gap we are closing is specifically Postmark event handling and visibility from the Control Panel — not general transactional email templating or analytics.
• We are comfortable pinning an exact version, vendoring the committed assets, and verifying their hashes in our own pipeline (do not rely solely on the upstream CI check).
• The team accepts pre-1.0 semver: minor releases at 0.x may carry behavior changes, and there is no LTS commitment.

Look elsewhere when:

• We need a stable public API or an SLA — 0.1.x plus a maintenance-only release cadence is not a GA-critical-path dependency.
• We run Statamic 5.x or an older Laravel, or we run Laravel without Statamic at all; the Control Panel integration is the point and adds nothing otherwise.
• We need capabilities beyond replay protection and CP visibility (delivery analytics, inbound mail routing, multi-tenant isolation) — those are unproven here.
• Committed build artifacts are a policy violation for us; this package ships them by design.

How to Pitch It (Stakeholders)

For executives: This is a small, narrowly scoped add-on that connects Postmark to our Statamic Control Panel and handles webhook replay protection so we do not have to build and maintain that logic ourselves. The latest release adds no new features — it is a security and build-integrity release: assets are rebuilt against a pinned, patched Statamic version and verified deterministically in CI, which is what we want to see from a dependency that touches email events. The trade-off is maturity: it is pre-1.0, so I recommend a timeboxed pilot with a pinned version and a documented fallback to in-house handling, not a production dependency on a revenue-critical path.

For engineering: Treat v0.1.13 as the adoption baseline — it rolls up the replay protection from v0.1.11 and the security lock refresh from v0.1.12. Pin the exact version, confirm our Statamic is at or above 6.31.0, and re-run asset hash verification in our own CI rather than trusting the upstream job. Budget for at least one breaking change before 1.0, and keep the Postmark integration behind an interface so we can swap it out.