Api Laravel Laravel Package

Product Decisions This Supports

• Feature: in-app support entry points. Create conversations from inside the product (order detail, account settings, error states) with the customer, mailbox, subject, and initial thread pre-populated — removing the "copy your account ID into an email" step that drives most support back-and-forth.
• Feature: customer context enrichment. Push product-owned attributes into Help Scout customer records (plan tier, MRR, seat count, onboarding stage, last login) so agents stop asking questions the product already knows. This is the highest-ROI, lowest-effort use of the package and directly moves time-to-first-response and first-contact-resolution.
• Feature: product-event-driven ticketing. Emit a conversation on failed payment, failed integration sync, or SLA breach, tagged and routed automatically. Turns silent failures into tracked support load.
• Feature: admin-side conversation history. Surface a customer's recent conversations in the internal admin/customer-360 view via the facade, so CS and Success see the same record without switching tools.
• Roadmap input: voice-of-customer pipeline. Pull conversations and tags on a schedule into the warehouse to quantify defect themes and feature demand — informs prioritization instead of relying on anecdote.
• Build vs. buy: buy the plumbing. The alternative is a hand-rolled HTTP client with auth, retries, error mapping, and DTOs that we own forever. This package gives config-driven credentials, container binding, and a facade — days of work collapsed into an afternoon, and it stays out of our domain code if we wrap it.
• Explicit non-decision: this package does not decide your support-desk strategy. It is a transport adapter. If the roadmap question is "Help Scout vs. Zendesk vs. Intercom," this package is a consequence of that decision, not an input to it.

When to Consider This Package

Adopt when:

• Help Scout is already the system of record for support — this is an integration, not a migration.
• The stack is Laravel or Lumen and the team already resolves services from the container; the facade fits existing conventions with near-zero architectural argument.
• Needs are mailbox-API-shaped: conversations, threads, customers, mailboxes, tags. Creating, reading, and tagging covers the large majority of product-led support use cases.
• You want the vendor's own client rather than a community wrapper — it is published under the Help Scout org, MIT-licensed, and actively released, so API drift is the maintainer's problem, not ours.
• You will wrap it behind a first-party interface (e.g., SupportDesk) so the dependency is swappable.

Look elsewhere or plan to build when:

• You need Help Scout surfaces beyond Mailbox API 2.0 — Docs, Beacon, Reports, or workflow endpoints. Verify coverage against the underlying PHP SDK before committing; a missing endpoint means hand-rolled requests anyway.
• You need inbound webhooks from Help Scout. Expect to build the receiving controller, signature verification, and idempotency yourself; the package is an outbound client.
• You are running bulk or bidirectional sync. Rate-limit handling, batching, backoff, and checkpointing are orchestration concerns above this layer and are yours to own.
• You need generated, strongly typed clients from an OpenAPI spec, or you are not on Laravel.
• Adoption risk is a real consideration. Nine stars and zero dependents means the community signal is essentially absent. Mitigate with a pinned version constraint, an integration test against a sandbox mailbox, and the adapter boundary above — the exit cost is then an afternoon, not a quarter.

How to Pitch It (Stakeholders)

For executives: We are integrating our product with Help Scout, the support desk our team already uses. This package is the official, MIT-licensed connector from Help Scout itself, so we are buying a supported component rather than funding weeks of custom plumbing. The business outcome is context and speed: agents see plan, revenue, and account state without asking, and support tickets can be created automatically when the product fails a customer. Cost is measured in days, not a headcount, and because we isolate it behind our own interface, switching support vendors later is a contained change rather than a rewrite.

For engineering: It is a thin Laravel service provider plus facade over helpscout/helpscout-api-php — config-driven credentials, container resolution, no opinions imposed on our domain. We will bind it behind a SupportDesk contract, pin the version, and cover it with a sandbox integration test. That gives us vendor-maintained API coverage without letting a low-adoption dependency reach into product code. Effort estimate: half a day for the wiring, the rest of the value is in deciding which product signals we push.