Selligent Client Bundle Laravel Package

Technical Evaluation

Architecture fit

The first thing a TPM must flag: this is a Symfony bundle, not a Laravel package. Bundles are Symfony's DI/configuration extension mechanism — they register services, compiler passes, and bundle-specific config trees. Laravel has no equivalent. Whatever value exists here lives in the underlying proglab/selligent-client (or similarly named) library; the bundle is a thin, framework-coupled wrapper around Selligent/Marigold Engage API access.

Consequences for fit:

• If the core client is framework-agnostic (likely, since bundles typically delegate), we can consume it from Laravel via a custom service provider and config binding. The bundle itself is dead weight.
• If the bundle contains Symfony-specific coupling (EventDispatcher, HttpKernel, Bundle config trees, service tagging), we would be porting, not integrating.
• Either way, the artifact we'd depend on is the underlying client, not this bundle. Confirm that assumption before anything else.

Integration feasibility

Feasible but low-confidence. This is a low-signal package: 1 star, 0 dependents, score 0.005. That is not "unpopular," it is "effectively unexercised" — the happy path may work, but edge cases, error handling, and version-constraint hygiene are almost certainly untested against anything but the author's original tenant.

The real gate is not code, it is access. Selligent/Marigold Engage is an enterprise marketing platform: credentials are contract-gated, instances are per-tenant, and APIs are frequently IP-allowlisted. We cannot validate this integration in CI without a provisioned sandbox tenant. Any estimate that doesn't include procurement lead time for that sandbox is wrong.

Second gate is API generation. Classic Selligent used SOAP/XML; Marigold Engage has been moving to REST. A package old enough to be a Symfony bundle with 1 star is plausibly targeting the SOAP surface. That changes the integration shape entirely — XML envelopes, WSDL codegen, fault handling, and a much heavier test harness.

Technical risk

• Vendor/abandonment risk (high). Single maintainer, no dependents, no observable community. Assume the project is dormant. Plan to fork and own, not to consume.
• Framework mismatch (high). Symfony bundle → Laravel app is a port, and it's the part of the work that carries no product value.
• Platform-access risk (high). Credentials, allowlisting, tenant provisioning, and Selligent-side schema (contact fields, consent attributes, segment definitions) are all external dependencies we do not control.
• PII/consent risk (high, but ours to manage). This package moves contact records and marketing consent state. Silent failures here are compliance incidents (GDPR consent drift, stale unsubscribe), not just bugs.
• Version/security risk (medium). Unmaintained packages accumulate unpatched transitive dependencies. composer audit and a PHP/Symfony constraint review are mandatory before adoption.
• Unknown test coverage (medium). With 1 star there's no evidence of a test suite that mocks the Selligent API; we'd be building that harness ourselves.

Key questions (must be answered before commit)

1. Does the bundle wrap a standalone, framework-agnostic client library — and is that library independently versioned and documented?
2. Which Selligent API surface does it target: SOAP or REST? Which API version, and is it still supported by Marigold?
3. What is the actual PHP and Symfony constraint range, and does it install cleanly on our target PHP 8.2/8.3?
4. Is there any test suite, and does it mock the API or require a live tenant?
5. What is the license, and does forking carry obligations?
6. Can we obtain a sandbox tenant, and who owns that vendor relationship?
7. Is the underlying client also effectively unmaintained, or is the bundle simply a stale wrapper over a live library?

Integration Approach

Stack fit

Poor as-shipped, workable with a wrapper. Recommended shape:

• Treat proglab/selligent-client-bundle as reference source, not a dependency. Read it to learn the auth flow, endpoint shapes, and payload mapping, then either (a) depend on the underlying client library directly, or (b) fork the client behind our own interface.
• In Laravel, define a SelligentClient contract in our domain layer and bind an implementation in a service provider. Nothing outside that provider should know the vendor library exists. This also keeps an exit path open if Marigold's REST API supersedes it.
• Keep the Selligent payload mapping in dedicated Data/DTO classes, not inline arrays in jobs. Contact schema and consent fields will change; mapping code should be isolated and unit-testable.

Migration path

There is no incumbent to migrate from — this is greenfield adoption, which is easier but removes the safety net of a known-good baseline.

1. Spike (1–2 weeks): fork, run composer audit, attempt install on our PHP version, stand up a minimal auth + single-contact-read call against a sandbox tenant. This spike is the go/no-go.
2. Harness: build a recorded-fixture test suite around the client so we can test without a live tenant. Without this, every future change requires sandbox access.
3. Adapter: implement our SelligentClient contract over the forked library; expose only the operations we actually need (upsert contact, read consent, push event) — not the full API surface.
4. Cutover: no legacy system means cutover is per-feature, behind flags, one operation at a time.

Compatibility

• Verify composer constraints resolve against our lockfile before estimating. A conflict here can invalidate the whole spike.
• If the client depends on PHP SOAP extension or specific cURL options, confirm our runtime images include them.
• If the library ships Symfony-specific classes at the top level, autoloading them in Laravel is harmless provided nothing instantiates them — check for stray use Symfony\... on the call path.

Sequencing

Security/license review and sandbox provisioning in parallel with the spike — they are the long-lead items and should not be sequenced after code exploration. Adapter design starts only after the spike proves a live call. Feature work starts only after the fixture harness exists.

Operational Impact

Maintenance

Assume we own this code. With 1 star and 0 dependents, upstream is a hope, not a plan. Budget for:

• A forked repo with our own CI, dependency updates, and patch cadence.
• An owner (named engineer, not a team) for the fork and for the Marigold vendor relationship.
• Quarterly review of the Marigold API changelog to catch deprecations — the vendor will not notify us through a Composer package.

Support

No community, no SLA, no issue-triage capacity worth counting on. Internal documentation of the auth flow, endpoint behavior, and quirks is not optional; it is the only support asset we will have. Treat the spike's findings as a deliverable artifact.

Scaling

Two separate concerns:

• Our side: the client is a synchronous HTTP wrapper. Contact syncs at volume need queueing, batching, backoff, and idempotency keys — none of which we should assume the package provides. Plan to wrap calls in Laravel jobs with retry/backoff and rate limiting.
• Vendor side: Selligent/Marigold imposes its own API quotas and throughput limits. Capacity planning is a conversation with the vendor account team, not a code change. Get the limits in writing during the spike.

Failure modes

• Silent partial success: batch contact upserts where some records fail and the client swallows per-record errors. Marketing sends to a stale segment. Highest-severity mode; requires per-record result validation and dead-letter handling.
• Consent drift: unsubscribe or preference change not propagated; compliance exposure. Needs verification reads, not fire-and-forget writes.
• Auth/credential expiry: token or credential rotation breaks syncs at 2am with no alerting from upstream. Needs our own health check and alert.
• Schema drift: Marigold-side contact field changes cause silent mapping failures. Needs schema assertions on startup or first call.
• Transitive dependency rot: unpatched packages in an unmaintained tree. Needs composer audit in CI and a scheduled update job.

Ramp-up

• Engineer time to productive: moderate — the API shape is not the hard part; the missing documentation and live tenant are. Expect 1–2 weeks to first successful call, 3–4 weeks to a tested adapter.
• Organizational ramp-up is the longer pole: procurement, security review of PII flow, and legal review of consent handling will dominate the timeline. Start those before the spike, not after.
• Recommend an ADR documenting the build-vs-buy decision explicitly, including the fallback of integrating directly against Marigold's REST API and skipping this package entirely. Given the package's signal quality, that fallback should be treated as a live option, not a contingency.