Companies House Laravel Laravel Package

Product Decisions This Supports

Frame it correctly first. This is a read-only HTTP client for the official UK Companies House API, dressed in Laravel conventions — a facade, a config file holding the API key, and typed responses for search, company profiles, officers, registered addresses, and filing history. It owns no tables, ships no migrations, and models nothing in Eloquent. The PM-relevant consequence: adoption is a tactical integration choice with almost no architectural gravity. The decision worth spending real time on is whether company verification belongs on the roadmap at all, not whether this particular library is the right one.

Decisions it actually informs:

• Onboarding and KYB-adjacent flows. Validating a company number at signup, confirming the legal entity name and status (active, dissolved, liquidation), and pre-filling the registered address are the classic requirements this unblocks. If B2B signups are leaking to manual entity checks, this is a cheap, fast experiment.
• Trust and risk surfaces. Incorporation date, company status, officer lists, and filing history support vendor-risk checks, marketplace seller verification, and the "is this a real business" signal that enterprise buyers and supply-side onboarding both ask for.
• Build vs. buy — but narrowly. The displaced build cost is a day or two of HTTP plumbing, auth, and DTO work. That's a small number, which means the real question is scope of commitment: a timeboxed spike behind a feature flag to test demand, then a separate decision on whether to invest in caching, persistence, and monitoring — or drop it.
• Data freshness as a product decision. Companies House data changes without webhooks. Whether the UI shows live lookups or a nightly snapshot is a UX and cost call. This package supports the former only; caching and staleness are yours to design and own.
• Sequencing against adjacent roadmap items. Verification is often a small, high-leverage feature that unblocks an enterprise deal or a marketplace supply motion. It's a good candidate for "validate demand before building the system."

What it does not support, and should not be sold as supporting: officer history, temporal queries ("who was a director on date X"), audit trails, or change notifications. The resigned_on field surfaced in release 2.0.4 is a pass-through from the upstream officer payload — it is not evidence of a governance data model. Correct that framing before it reaches a roadmap.

When to Consider This Package

Worth considering when:

• You're on Laravel and need read-only UK company lookups inside an existing service, and you'd rather use facade and config conventions than hand-roll Http:: calls.
• The feature is adjacent rather than core — a verification badge, a seller-check step, an internal admin lookup. If Companies House data is the product, you want a client you own, with caching, retries, and observability baked in.
• You're validating demand before committing to a build. Wrapping this for a spike or MVP is a rational, low-cost move.
• You're willing to pin the version, read a few hundred lines of source, and fork or vendor it under the MIT licence if the maintainer disappears.

Look elsewhere — or write the client yourself — when:

• Framework compatibility is unverified. The last release was September 2021, pre-Laravel 10/11. Read composer.json before anything else; the constraint ceiling may simply rule it out for a modern codebase.
• Adoption signal matters to you. 22 stars, zero dependents, one maintainer. There is no ecosystem evidence of production use, which means no battle-testing and no crowd-sourced bug reports. Fine for a throwaway spike; a real gap for a customer-facing compliance surface.
• You need more than request/response. Retries, backoff, caching, rate-limit budgeting, pagination across filing history, error taxonomy, and metrics are all yours to build. At that point the wrapper's marginal value is small.
• You need webhooks, incremental sync, or change detection. Companies House notifications are a separate product with separate registration; this package does not address them.
• Procurement or legal review is in the path. Officer data is personal data under UK GDPR, and Companies House terms govern storage, display, and onward use. A package with no security policy, no DPA, and no maintainer SLA will not survive that review — you need your own position regardless of library.
• You need multi-jurisdiction coverage or uptime guarantees. UK-only by definition, with no SLA beyond GitHub issues.

Open questions to resolve in the spike: supported Laravel/PHP versions; whether the API key comes only from config; how 401/404/429/5xx surface; whether the company-number validator is offline (checksum) or API-dependent — offline is far more useful in a signup form; whether there's a fake mode for tests; and whether rate-limit headers are exposed.

How to Pitch It (Stakeholders)

For executives. We can add UK company verification — confirming a business is real, active, and who runs it — in days rather than weeks by wiring a small MIT-licensed Laravel connector to the official Companies House API. It's free, read-only, and stores nothing, so there's no lock-in and no data-ownership problem created by the library itself. Two caveats to state plainly: the library is low-adoption and last released in 2021, so this is a small, reversible commitment rather than a strategic platform bet; and the payoff depends entirely on whether verification unblocks a customer segment or a marketplace supply motion. Recommend a timeboxed spike behind a feature flag with a go/no-go gate, not a standing dependency.

For engineering. Treat this as an anti-corruption layer between our app and an external registry, not a domain model — no migrations, no Eloquent entities, nothing to extend. That makes it cheap to try and cheap to discard. Two things to settle first: Laravel/PHP version compatibility given the 2021 release date, and whether we adopt the wrapper or read it as reference and write our own ~200-line client. Either way, put it behind a CompanyRegistry interface so facade calls never reach controllers or Blade, and own the parts the package doesn't provide: caching keyed by company number with an hours-scale TTL, retry/backoff, rate-limit budgeting, filing-history pagination, and error mapping that distinguishes Verified / NotFound / Dissolved / Unavailable — "company not found" is a valid product result, not an error, and must not be collapsed into one.

On risk. The package's smallness is both the pitch and the caveat: low blast radius if abandoned, but equally low evidence anyone has run it in production. Pin the exact version, read the source, keep the fork option open, and treat replacement as a contained afternoon rather than a migration project. Separately, flag early that officer names are personal data under UK GDPR and Companies House carries usage and attribution terms — we need a legal read on retention and UI copy before this ships to customers, independent of which library we pick.