Laravel Trustpilot Laravel Package

Product Decisions This Supports

• Build vs. buy for Trustpilot integration: this package collapses the "do we build our own Trustpilot client?" question. A single Composer dependency covers auth, endpoints, and error handling; the alternative is days-to-weeks of internal plumbing that adds no product differentiation.
• Review collection roadmap: invitations() (email invitations, invitation links, templates) is the highest-leverage surface. It unlocks post-purchase or post-support-ticket invite flows as a config change, not a project — directly feeding review volume, which drives ratings and downstream SEO/seller-rating eligibility.
• On-site social proof: businessUnits() (search, get, profile, categories, web links) plus reviews() public list/get/latest makes "show real Trustpilot reviews on PDP/marketing pages" a small, self-contained ticket rather than a data-pipeline initiative.
• Review operations / customer support workflow: reviews() private list + reply + delete reply enables a moderation/reply queue. This is a support-ops feature, not engineering work, and can be scheduled by the CX team rather than the platform team.
• Multi-brand / multi-location architecture: first-class business units plus a configurable default mean the same code path serves N storefronts or regions — relevant if the roadmap includes expansion into new markets or sub-brands.
• Taxonomy and reporting consistency: tags() (get/add/remove) lets us standardize internal review categorization, which makes sentiment reporting comparable across business units and quarters.
• Buy-vs-adapt signal for adjacent decisions: because public endpoints use API key auth and private ones a cached client-credentials token, the auth model is already aligned with a server-side Laravel app. No new secret-management or proxy tier is implied by adoption.

When to Consider This Package

Adopt when all of the following hold:

• Trustpilot is the chosen (or committed) review platform — this is Trustpilot-specific, not a multi-source review aggregator.
• The stack is Laravel/PHP and the integration is server-side; the auth model assumes a confidential client that can safely hold credentials.
• The near-term scope is one or more of: displaying reviews, sending invitations, replying to reviews, or reading business-unit metadata.
• The team is comfortable pinning a 1.0.0 dependency and treating it as a thin, replaceable adapter (wrap it behind our own interface rather than calling it from controllers and Blade templates).

Look elsewhere — or plan to build the missing layer — when:

• Multi-platform review aggregation is the actual requirement (Google, Trustpilot, G2, etc. in one inbox). This solves one source.
• Event-driven reactions are needed. There are no webhooks here; detecting new reviews means polling latest, which has cost and latency implications for a "reply within the hour" SLA.
• Robustness matters more than simplicity. Every non-2xx becomes a TrustpilotException, and the release notes describe no retry policy, backoff, or rate-limit handling. Fine for a dashboard; risky inside a checkout or order-confirmation path where a third-party outage could fail a customer-facing flow. Budget for a queue and our own retry wrapper.
• Product-level reviews, review images/media, or rich reporting are on the roadmap — none are in this release.
• Granular failure handling is required (e.g., distinguishing "already invited" from "invalid email" from "quota exceeded"). A single exception type pushes that parsing into our code.
• Team lacks PHP/Laravel — the value here is idiomatic integration, not the API itself.

Maturity note: this is a first release. Expect surface-level gaps and breaking changes before 1.x stabilizes. Pin the version, and keep our usage behind a narrow internal interface so a swap or a fork stays cheap.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can integrate Trustpilot into our product in days instead of weeks. This package gives us the four things that actually move the metric — showing reviews where customers decide, automatically inviting customers to review us after purchase or support, replying to reviews from our own admin tools, and segmenting by brand or region. That combination is what lifts review volume and star ratings, which in turn supports conversion and paid/organic visibility. Cost is one dependency; the risk is low and reversible because it's a thin wrapper we control.

For engineering: A Laravel-native Trustpilot client at 1.0.0 covering business units (search/get/profile/categories/web links), reviews (public list/get/latest, private list, reply, delete reply), invitations (email, links, templates), and tags. Auth is handled: API key for public endpoints, cached client-credentials bearer for private. One configurable default business unit. All non-2xx responses raise TrustpilotException.

Three things to plan around before we commit:

1. No webhooks. New-review detection is polling-based; design the reply workflow as a scheduled job with a sensible interval, not an event stream.
2. Coarse error surface. One exception type and no documented retry/backoff. Wrap calls in our own adapter with explicit retry and quota handling; never call it inline in a customer-blocking path.
3. First release. Pin the version and depend on an internal interface, not the package's API directly, so upgrades are contained.

Recommendation: adopt for review display, invitations, and the reply workflow; treat it as a swappable adapter and avoid it on any latency-sensitive customer-critical path until it has a few releases behind it.