Core Lib Laravel Package

Technical Evaluation

Architecture fit

The most important thing a TPM can do here is reclassify the artifact before anyone adds it to composer.json. mautic/core-lib is the shared core of the Mautic distribution — the entities, repositories, services, and event hooks that Mautic's own bundles extend. It is published as a Composer package so the Mautic monolith and its bundles can depend on it, not so that unrelated applications can. The metadata confirms the intent: 6 stars, 0 dependents, last release August 2022. If it were a viable third-party library it would have consumers by now. It does not.

So the architecture decision is not "which package do we install" but "do we operate a Mautic instance as a separate service." The answer, if yes, looks like: Mautic deployed on its own subdomain with its own PHP-FPM/Symfony 4.4 runtime, MySQL/MariaDB, and the full cron suite; our Laravel application talking to it over the REST API (basic auth for server-to-server, OAuth2 only if you genuinely need per-user scoping) and receiving form-encoded webhooks; a thin MauticClient interface binding the framework-agnostic mautic/api-library SDK inside a queued job layer; optionally mtc.js in the Blade layout for client-side tracking. Coupling is HTTP, so Laravel and Mautic version-drift independently — a benefit, and also a reason Composer's conflict resolution gives us no safety net at all.

Integration feasibility

Feasible, and the integration surface itself is small — an experienced engineer can complete an end-to-end spike (authenticate, upsert a contact, add to a segment, receive a webhook) in under a week. What makes it non-trivial is everything around the API call:

• Provisioning and hardening a second PHP application, including its cron suite (segments, campaigns, imports, email queue).
• Identity mapping between our users/leads and Mautic contacts, keyed on email, with a local mautic_contact_id column and a backfill job.
• Pre-provisioning custom field aliases — the API will not create them, and pushing an unknown alias silently drops the value.
• An outbox/queue pattern so no user-facing request ever waits on Mautic.
• Idempotent webhook consumers, because Mautic retries and payload shapes vary by trigger.
• Reconciliation for contacts that arrive via form submissions and never map back.

Rough sizing for planning: one engineer-week for the spike, three to five engineer-weeks for contact sync, segment/campaign consumption, and webhook handling, plus ongoing platform ownership. That is the number to put in front of whoever asked for marketing automation.

Technical risk

• Misclassification risk (highest). Every artifact around this package describes it as a library. Stakeholders will assume composer require and a sprint of work. Correct that in the first meeting, in writing.
• Version/EOL risk. The only release on record is 4.4.1 from August 2022, targeting Symfony 4.4 and PHP 7.4/8.0. If our runtime baseline is PHP 8.2+, we are greenfielding onto a stack we cannot patch forward cheaply. That makes Mautic 5 the more defensible default and turns 4.4.1 into a reference point, not a target.
• Adoption risk. Zero dependents and a stale release cadence mean thin community support for the library specifically. We own our client code outright; there is no upstream to lean on and no third party to blame.
• Data and compliance risk. Contact PII and engagement history land in a second datastore. GDPR access and erasure flows now span two systems, and consent state has exactly one correct source of truth — pick it deliberately.
• Operational ownership risk. We inherit uptime, backups, patching, CVE response, and cron health for a second application, with an ownership boundary that marketing ops and engineering will both assume the other side covers.
• Patch-release risk is genuinely low. 4.4.1 is maintenance-only: bug fixes, no new features, no API or schema breakage. The upgrade is composer update in the Mautic root, doctrine:migrations:migrate, cache clear. It does not touch our integration contract. The risk is not this release; it is the habit of deferring Mautic releases generally.

Key questions

1. Is the underlying requirement marketing automation, or would a hosted ESP (Mailchimp, SendGrid, HubSpot, Customer.io) satisfy it with a fraction of the operational surface? Force an explicit comparison before committing.
2. What is our PHP runtime baseline, and does that rule out 4.4.x entirely in favour of Mautic 5?
3. Has anyone confirmed the package is not Laravel-installable, or is that still an open assumption in the plan?
4. Who owns patching and CVE response for the instance — platform engineering or marketing ops — and is that written down?
5. What is the source of truth for contact identity and consent status?
6. Do we need bidirectional sync, or is one-way push plus webhook-driven pull sufficient? Bidirectional roughly doubles the reconciliation work.
7. Is there a customer-facing SLA implication? If so, self-hosting community-supported Mautic 4.4 is the wrong answer and a commercial Mautic host is the right one.
8. Is there any requirement that would justify embedding Mautic inside our Laravel deployment? (Strongly advise against; the answer should be no.)

Integration Approach

Stack fit

Poor as a library, acceptable as a service. Mautic's Symfony 4.4 DI container and Doctrine ORM are entirely disjoint from Laravel's container and Eloquent; do not attempt to bootstrap Mautic inside a Laravel process. The seam that does fit is HTTP: Mautic's REST API is conventional JSON, and its webhooks are plain POSTs our existing queue workers can consume. Use mautic/api-library (framework-agnostic PHP, installs cleanly via Composer) behind our own MauticClient interface rather than calling SDK classes directly from controllers — that interface is what lets us swap to a hosted provider later without rewriting call sites.

Migration path

Nothing is currently installed, so this is provisioning and cutover rather than migration:

1. Decide the version. Answer the PHP-baseline question first. Greenfielding on 4.4.1 in 2024+ is a decision that needs a stated rationale, not a default.
2. Provision the instance in its own environment behind the reverse proxy, on a dedicated subdomain, isolated database, restricted egress.
3. Configure the API user, auth mode (basic auth is the pragmatic default for server-to-server), webhook endpoints, custom field aliases, and the full cron suite. Cron omission is the single most common cause of "Mautic is broken" tickets.
4. Build MauticClient with retry/backoff, a queue-backed outbox for writes, and a circuit breaker. Bind it as a singleton in a service provider so auth construction happens once, not per call.
5. Add identity mapping: mautic_contact_id on the relevant local models plus a backfill job using createBatch()/editBatch() at 100 records per request.
6. Cut over one channel at a time, transactional email last, with a reconciliation job running throughout to catch drift.

Compatibility

4.4.1 is API-compatible with the rest of the 4.4 line. The endpoints we would consume — /api/contacts, /api/segments, /api/emails, /api/forms, /api/fields — are stable across 4.x, and webhook payload shape is unchanged. Our Laravel version is irrelevant to compatibility because the coupling is HTTP. That also means compatibility is entirely our responsibility to manage: pin the Mautic version in infrastructure config, treat the API surface as a versioned interface with a contract test in CI, and remember that /api/leads and /api/contacts are the same resource under two names, which will confuse anyone reading the docs cold.

Sequencing

Phase 1 — spike: provision, authenticate, upsert and read back a contact, receive one webhook, confirm a segment triggers a campaign. This single path exercises auth, field aliases, the contacts endpoint, the segments endpoint, and cron — the five things that break first.

Phase 2 — contact sync and identity mapping, including backfill and reconciliation.

Phase 3 — segments and campaign data consumed by our application.

Phase 4 — email sending and engagement webhooks.

Phase 5 — bidirectional consent handling, erasure flows, and PII retention across both stores.

Insert a formal go/no-go gate at the end of Phase 1. The spike is cheap; the three-year operational commitment is not, and the decision is materially easier to reverse at that point than at Phase 4.

Operational Impact

Maintenance

We take on a complete second PHP application: Composer updates in Mautic's own root, database migrations, cache rebuilds, the cron suite, and the eventual major-version upgrade to Mautic 5. Budget roughly one platform engineer at partial allocation for steady state, plus explicit marketing-ops ownership of configuration, campaigns, and segments. The 4.4 line will stop receiving security fixes; that date belongs on the roadmap on day one rather than surfacing as an incident. If we adopt 4.4.1, we should also budget the 4.4 → 5 migration before we have finished the initial build.

Support

Support splits awkwardly and will generate bounced tickets unless a written RACI exists. Nominally: marketing ops owns campaigns, segments, and templates; engineering owns the instance, credentials, webhook reliability, and patching. In practice every ambiguous issue lands on engineering. Note that Mautic 4.4 is community-supported — for anything customer-facing, a commercial Mautic host is usually the better procurement decision, trading licence cost for a supported upgrade path and a named escalation route. That comparison should be on the table before we self-host.

Scaling

Mautic scales like a monolith: vertically first, then read replicas. Its cron-driven segment rebuild degrades as the contact table grows — plan for segment sizes in the hundreds of thousands rather than millions without dedicated tuning, and treat contact-table growth as a capacity signal to watch, not a surprise. Our Laravel side scales independently as long as every Mautic call is queued rather than made in the request cycle. Also watch pagination: offset-based, limit hard-capped at 100, and no trustworthy total, so any sync loop must walk until an empty page rather than iterating a count.

Failure modes

• Mautic down or slow — must not degrade our application. Circuit breaker on the client, outbox for writes, no synchronous contact upserts from user-facing requests.
• Cron not running — segments and campaigns go silently stale; emails queue but never send; nothing errors. Alert on cron heartbeat, not on error logs.
• Webhook duplication — Mautic retries. Consumers must be idempotent, keyed on event ID.
• Webhook content type — payloads are application/x-www-form-urlencoded, not JSON. This is the most common integration bug and will break naive receivers.
• Auth misconfiguration or token expiry — produces broad 401s that read like an outage. Rotate credentials on a schedule and alert on 401 rate.
• Silent field drops — pushing a value to a non-existent alias succeeds and discards the data. Validate the alias map at deploy time.
• Identity drift — contacts created by form submissions that never map back to our records. Needs a scheduled reconciliation job, not manual triage.
• Instance compromise — contact PII is the blast radius. Isolate the database, restrict egress, and log API access.
• Patch lag — this release is low risk, but the pattern of deferring Mautic upgrades is the real operational exposure.

Ramp-up

Two to three weeks for an engineer new to Mautic to be productive in its Symfony codebase and API conventions; the API integration surface alone is a few days. Marketing-ops training on segment and campaign building is the longer tail and the more likely schedule risk. Three artifacts eliminate most of the recurring support load and should be written during Phase 1, not after launch: a cron-suite runbook, the OAuth/basic-auth setup and credential rotation procedure, and the contact identity and consent model.