Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Recherche Entreprises Bundle Laravel Package

philippe2463/recherche-entreprises-bundle

A Symfony bundle that integrates the French Recherche d'entreprises API, letting you search companies by name, SIREN/SIRET, or location and retrieve structured business data directly in your PHP applications.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

French-market B2B features, not general company data. This bundle is a thin Symfony service layer over the French government's Recherche d'entreprises API (a free, keyless, rate-limited public service). The PM value is narrow and concrete: it turns "we need company lookup" from a multi-week build into a configuration task, but only for French legal entities. Use it to scope these roadmap items:

  • B2B signup and onboarding. Company-name autocomplete and SIREN/SIRET validation at the point of registration. Removes manual data entry and the classic "customer typed their own legal name three different ways" data-quality problem before it reaches the CRM.
  • KYB / seller onboarding for marketplaces. Lookup of legal form, NAF/APE code, headcount band, creation date, and registered address gives an underwriting signal without a commercial data vendor.
  • Invoicing and accounting compliance. French invoices require legal entity identification (name, address, SIREN, VAT number). Auto-filling these reduces the error rate on a document class you cannot afford to get wrong.
  • CRM and lead enrichment. Deduplication by SIREN, segmentation by NAF code and region, firmographic filters for sales targeting.
  • Data-quality backfill. A one-off job to normalise an existing company table against the official registry.

Build vs. buy — reframe it as "adopt vs. wrap." The underlying API is free and public, so there is no vendor contract to negotiate and no license line item. The real decision is whether a third-party wrapper saves more engineering time than it costs in dependency maintenance. At 0 stars, 0 dependents, and a single maintainer, that answer is usually "vendor the five classes you need, or call the API directly from a small internal client." What this package is genuinely useful for is scoping: it demonstrates that the integration is a day of work, not a quarter. Present it to stakeholders as evidence for a roadmap estimate, not as an architecture commitment.

It does not support vendor selection. Nothing here helps you choose a multi-country data provider, and the API it wraps is France-only, read-only, and carries no SLA. If the roadmap includes UK, German, or Dutch company lookup, this package is not a step toward that — a commercial aggregator is.

When to Consider This Package

Adopt (or copy) when all of these hold:

  • You are on Symfony. This is a Symfony bundle with service-container integration and auto-configuration. In a Laravel codebase the bundle gives you nothing — you would call the API with Http::get() in a small service and skip the dependency entirely. Confirm the framework before the conversation goes further.
  • The need is read-only and France-only. Search and lookup by name, SIREN, or SIRET with pagination. No writes, no webhooks, no auth flows.
  • The blast radius is small. It belongs in a lookup or enrichment path, never in the payment, auth, or data-integrity path. Worst-case failure is a degraded form field, not a broken checkout.
  • Your Symfony and PHP versions are inside the bundle's composer.json constraints. Check constraints, not the README — this is the cheapest disqualifier and the last thing a 0.x bundle will tell you about itself.
  • You accept the upstream API's terms. Public, rate-limited (~7 req/s), no uptime guarantee, no support contract. Plan for caching and a graceful fallback ("enter your details manually") the moment it is unavailable.

Look elsewhere, or build the small client yourself, when:

  • You need multi-country coverage, SLAs, or enriched data (financials, ownership graphs, credit scores). That is a paid vendor decision, not a bundle decision.
  • You are on Laravel or framework-agnostic PHP. A Symfony bundle introduces a framework coupling you would have to unpick.
  • You need officers/directors data or anything touching personal data. Director names are personal data under GDPR; that triggers a legal review that dwarfs the integration cost, and it should be a conscious product decision rather than a side effect of adding a dependency.
  • The maintainer goes quiet. Zero stars, zero dependents, and a single maintainer is the highest-decay dependency class. Do not put it on a critical path you cannot replace in an afternoon.
  • The license or the fork bothers your legal team. It is MIT, which means forking is explicitly permitted — treat that as the exit strategy and confirm the team is comfortable owning a fork.

How to Pitch It (Stakeholders)

To executives: For our French B2B features — company autocomplete at signup, invoice legal-entity details, seller onboarding — this reduces the integration from weeks of plumbing to roughly a day, at zero license cost. The important framing is that we are not buying a vendor: the data comes from a free French government API, and this package is a small community wrapper around it. So the benefit is speed, the cost is near zero, and the risk is a dependency we may end up owning. We mitigate that by keeping it behind our own interface, which means switching to a direct API call or a commercial provider later is a contained change rather than a rewrite. Net: it de-risks the estimate for the French-market roadmap items more than it de-risks the architecture.

To engineering: This is a lightweight, MIT-licensed Symfony bundle that wires up the Recherche d'entreprises API — search by name/SIREN/SIRET, pagination, configurable client settings. My recommendation is not "install and call it from controllers," but "use it as the reference implementation and wrap it." Concretely: define our own CompanyLookup interface and a small adapter, so the bundle is an implementation detail we can replace with an in-house HTTP client or a paid provider without touching call sites. Verify the composer.json constraints against our current and next Symfony major, pin the version, add it to the dependency-review and Renovate/Dependabot watchlist, and write one smoke test that asserts a real lookup returns an expected company — not merely that the container resolves the service. Known failure modes to design around: the upstream API is rate-limited and has no SLA, so cache aggressively and degrade gracefully; and a bundle that silently stops auto-registering after a framework upgrade is a classic 0.x trap. Estimated effort for the adapter plus a real test is a couple of days; that is the number to put against "build our own client," which is not much more.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
skyraptor/chatter
edlugz/sasapay
abbasudo/artisan-route
mirvan/ippanel
ignibyte/aic-framework
glavweb/data-schema-bundle
glavweb/datagrid-bundle
tacticmedia/scim-server
uni-method/frame
neika-ai/sdk
adachsoft/php-code-style
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
adachsoft/api-version-bundle
cgv/localized-resource