Ekomi Api Bundle Laravel Package

Technical Evaluation

Architecture fit

• Despite being listed as a "Laravel/PHP package," this is a Symfony bundle (DI extension + config tree + service definitions). There is no service provider, no facade, no Laravel integration point.
• Functionally it is a thin wiring layer over an Ekomi PHP API client: it exposes shop ID / interface key configuration and registers client services. Logic density is very low, which cuts both ways — low value to adopt, low cost to replace.
• 0 stars, 0 dependents, archived January 2020. This is not a dependency you consume; it is a dependency you would have to own.

Integration feasibility

• Last release predates PHP 8 and Symfony 5/6. Expect Composer constraint conflicts against PHP 8.2/8.3 and Symfony 6/7; resolution will likely fail without a fork that widens constraints, or --ignore-platform-reqs (not acceptable for production).
• The underlying capability is small: authenticate, submit an order for review solicitation, retrieve shop/product reviews. That is a handful of REST calls — reproducible in a short spike.
• In a Laravel codebase, integration is via the underlying API client or a hand-rolled HTTP client, not this bundle.

Technical risk — High, concentrated in three places:

1. Unmaintained code: no security advisories, no PHP/Symfony compatibility work, no transitive dependency patching.
2. API lifecycle uncertainty: Ekomi API v3 is the contract; there is no evidence in the repo that the vendor still supports it. Vendor consolidation in the reviews space is a live concern and must be verified commercially, not from the README.
3. Privacy exposure: review solicitation transmits customer email, name, and order reference to a third party. GDPR/DPA, retention, and erasure propagation are all unaddressed by the package.

Key questions

• Does Ekomi still support API v3, and do our contract credentials still authenticate? Has the vendor been absorbed into another platform (e.g., Trusted Shops / eTrusted)?
• What does the bundle add beyond the underlying client — DI config only, or also console commands / event subscribers worth preserving?
• Which Symfony/PHP matrix can we realistically resolve today?
• Is the scope review solicitation (outbound PII), review display, or both? Only solicitation carries real compliance weight.
• Is there a signed DPA and a documented erasure path?

Integration Approach

Stack fit

• Laravel (primary case): do not install this bundle. Choose either (a) the underlying PHP API client as a direct Composer dependency, or (b) a ~150–250 line HTTP client against the documented endpoints. Bind whichever behind a ReviewProvider interface in a service provider — that interface is the Laravel equivalent of what the bundle provides, and it isolates the vendor.
• Symfony (legacy 4.4/5.x): the bundle can be installed with pinned constraints, registered in config/bundles.php, and configured with shop ID / interface key sourced from environment secrets. Acceptable only as a short-lived bridge.

Migration path

• Fork the archived repo into private VCS (or vendor-copy the source), widen constraints, and add a CI matrix across PHP 8.1–8.3 and the Symfony versions we run. Keep the public service surface identical so a later swap to the vendor SDK — or to another reviews provider — is a configuration change rather than a refactor.
• If the fork exceeds ~3 engineer-days of repair, abandon it and go direct to the API behind the same adapter. The bundle's marginal value does not justify more.

Compatibility and sequencing

1. Spike (2–3 days): confirm credentials and API v3 liveness, enumerate the endpoints actually needed, test Composer resolution against the target stack.
2. Adapter + configuration: ReviewProvider interface, secrets management, sandbox credentials.
3. Async wiring: order-shipped / fulfillment event → queued job → review invitation, with an idempotency key per order.
4. Observability: structured logs, success/failure metrics, dead-letter queue, alert on sustained 4xx.
5. Vendor checkpoint at ~6 months: contract terms, API version status, alternative provider shortlist.

Operational Impact

Maintenance

• No upstream. We own security patching, PHP/Symfony upgrades, and any API drift. Realistic budget: 3–5 engineer-days of initial hardening (fork, CI matrix, adapter, tests) plus ~2 days/year, with an unscheduled spike at every PHP or Symfony major bump.

Support

• None. No maintainer, no issue triage, 0 dependents means no community answer exists for the first failure. Vendor support is entirely a function of the commercial contract; API documentation is often gated behind an account.

Scaling

• Throughput is not the constraint — volume is roughly one API call per order. The constraints are isolation and correctness: queue every outbound call, retry with exponential backoff, cap concurrency, and never let an Ekomi timeout sit in the checkout or fulfillment critical path.

Failure modes (ordered by likelihood)

• CI/Composer breakage on the next PHP or Symfony upgrade.
• Silent API v3 deprecation: every call returns 4xx, and the only symptom is a slow decline in review volume.
• Credential rotation or expiry producing generic auth errors that are not alerted on.
• Duplicate review invitations when a queued job retries without an idempotency key.
• PII (email, order reference) leaking into application logs.
• GDPR erasure requests not propagated to the vendor.
• Unpatched transitive dependencies with no advisory feed watching them.

Ramp-up

• Small surface area; a mid-level PHP engineer is productive in 1–2 days. The real onboarding cost is the vendor's API semantics and the business rules around when a review invitation should fire — not this package.

Bottom line: the 0.015 score is an accurate read. Treat this as source to fork or as a reference implementation, not as a maintained dependency — and for a Laravel codebase, skip it entirely and build the thin adapter directly.