Salesmanago Api Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and the framing is wrong. Despite the request describing this as a "Laravel/PHP package," pixers/salesmanago-api-bundle is a Symfony bundle. Its integration surface is Symfony-specific: a Bundle class registered in AppKernel, a DependencyInjection/*Extension that parses a configuration tree, and YAML/XML service definitions. None of that is meaningful in Laravel, which has no bundle kernel, no DI extension compiler pass, and no concept of a bundle config tree. There is no service provider, no facade, no publishable config, no composer.json extra.laravel block. In a Laravel codebase this package either does nothing when installed or requires a hand-written bridge that amounts to a rewrite of its glue layer.

What is plausibly reusable is the inner layer: an HTTP client wrapping SalesManago's REST endpoints (contact upsert, event tracking, email/funnel triggers, consent fields). The value is in the request/response mapping against SalesManago's API semantics, not in the Symfony wiring — and the wiring is roughly 80% of what the bundle actually ships.

Integration feasibility — low without a rewrite. A Laravel TPM should assume this is a reference implementation, not a dependency. Feasible path: read the source to extract endpoint contracts, auth flow, and payload shapes, then reimplement as a Laravel service provider over Guzzle or Saloon. That is a multi-day spike plus a build, not a composer require.

Technical risk — high, concentrated in staleness and API drift. Last release 2016-08-17, roughly nine years stale. That era implies Symfony 2.8/3.x, PHP 5.6/7.0 constraints, and Guzzle 5/6 — all of which conflict with any modern Laravel (10/11/12, PHP 8.2+). SalesManago's API has moved on since 2016; endpoint versions, auth, and consent/data-protection fields have almost certainly changed. Signal quality is the real story: 1 star, 0 dependents, single-vendor origin (Pixers, a poster-printing e-commerce company). This was an internal extraction, not a community project. No dependents means no one is filing issues, no one is patching, and no one has validated it against the current API.

Key questions to resolve before any code:

• Which SalesManago capabilities do we actually need — contact sync, event tracking, transactional email, consent management, webhooks? The bundle's coverage in 2016 is not evidence of current coverage.
• Is there a maintained upstream? SalesManago publishes official API docs and there may be a current PHP SDK; a vendor-supported client beats a nine-year-old bundle.
• GDPR posture: SalesManago is EU/Poland-hosted and processes contact PII and consent state. Where does the bundle handle consent flags, and does it match our DPA and data-residency requirements?
• What is the license obligation under BSD-3-Clause if we fork — attribution in our repo, and are we comfortable owning a fork with no upstream to merge from?

Integration Approach

Stack fit — mismatch by construction. Symfony bundle → Laravel is a port, not an install. Budget for it explicitly rather than discovering it in sprint one.

Migration path — extract, don't adopt. Four candidate options, in preference order:

1. Vendor SDK / direct API. Use SalesManago's current documented API through a thin, first-party Laravel wrapper (Saloon or Guzzle + a typed client). Lowest long-term cost; you own the contract but not the framework glue.
2. Fork-and-port. Lift the bundle's request builders and response DTOs into a private package, replace the DI extension with a Laravel service provider, config file, and facade. Best when the bundle encodes non-obvious SalesManago quirks (auth token refresh, pagination, error envelopes) that would otherwise be rediscovered.
3. Adapter shim. Wrap the Symfony bundle inside a Laravel provider by booting a minimal container bridge. Technically possible, operationally indefensible — you inherit Symfony's DI semantics and the 2016 dependency tree while gaining nothing.
4. Drop it. If the needed surface is 2–3 endpoints, a 200-line client is cheaper than any of the above.

Compatibility gates that will decide this fast: PHP constraint in composer.json (likely ^5.6 || ^7.0), Symfony framework-bundle constraint, Guzzle major version, and whether services are defined in XML/YAML (portable) or rely on removed compiler passes (not portable). Run composer why-not against the target Laravel version before committing — expect an immediate hard block.

Sequencing:

1. Inventory (0.5 day). Enumerate the SalesManago operations the product needs; map each to the bundle's methods or confirm the gap.
2. Spike (2–3 days). Hit the live SalesManago sandbox directly with the current API, no bundle. Confirm auth, rate limits, payload shapes, and that the 2016-era endpoints still exist.
3. Build-vs-fork decision (gate). If the spike shows clean, documented endpoints, build the thin client and use the bundle only as reference. Fork only if the quirks are material.
4. Wrap (1 sprint). Laravel provider, config, credentials in secrets manager, contract interface plus a fake for tests, integration tests against a sandbox.
5. Rollout. Feature-flag behind an internal interface so a swap to a vendor SDK later is a one-class change. Queue all outbound syncs from day one — never call SalesManago inline in a request path.

Operational Impact

Maintenance — you own 100% from hour one. There is no upstream to merge from; a 2016 last release with 0 dependents is a frozen artifact. If you fork, you are the maintainer of record for a BSD-3-Clause fork, including security patches to whatever transitive HTTP stack it pins. If you build thin, you own less code but still own API drift. Either way, assign a named owner and put a recurring review on the calendar (quarterly: does the API contract still hold?).

Support — none. No vendor relationship, no community, no SLA. Escalation for "SalesManago changed a response shape" is internal engineering. This is the dominant hidden cost and should be priced into the business case, not treated as a footnote.

Scaling — HTTP-bound, and SalesManago's rate limits are the ceiling. Contact syncs and event tracking should run through queues with batching, exponential backoff, and idempotency keys so retries don't duplicate contacts or double-count events. Expect 429s under bulk import; design a token-bucket or concurrency cap per environment. Watch PII volume — bulk contact pushes amplify both latency and GDPR blast radius.

Failure modes to instrument:

• Silent contract drift — API changes a field or status code; no version pin protects you. Alert on non-2xx rate and on schema-validation failures at the client boundary.
• Auth/token expiry — 2016-era token refresh logic may not match current OAuth flow; a stale token fails every downstream sync.
• Partial batch failure — SalesManago accepts a batch and rejects individual records; without per-record result parsing you get silent data loss.
• Rate-limit storms — retries without jitter compound throttling during bulk operations.
• Consent/PII errors — writing contacts without correct consent state is a compliance incident, not a bug. Validate consent fields before send, and log opt-out propagation end to end.
• Credential exposure — verify the bundle doesn't log request bodies or echo API keys in exception messages; audit before production.

Ramp-up — the framework gap is the cheap part. A competent Laravel engineer unfamiliar with Symfony bundles needs a day to read the DI wiring; the real cost is 3–5 days learning SalesManago's data model, consent semantics, and error envelopes, which no one on the team currently knows. Plan for one engineer to own the SalesManago domain end to end, and pair that with a written internal runbook covering auth rotation, rate-limit tuning, and the escalation path for contract drift. Total realistic estimate to a production-capable integration: 1.5–2.5 engineer-weeks, dominated by the API learning curve rather than by porting the bundle.