Laravel Apollo Laravel Package

Product Decisions This Supports

• Build vs. buy for GTM data: This package makes "buy" concrete—instead of building a contact/company database or scraping pipeline, you integrate Apollo.io behind a thin Laravel abstraction. The decision becomes a vendor contract, not an engineering roadmap item.
• Lead-gen and prospecting features: People search + organization search map directly to an internal "find prospects" or "build a list" workflow—useful for sales tools, recruiting products, marketplace supply seeding, or partner discovery.
• Enrichment as a product surface: Single and bulk people enrichment plus organization enrichment support features like auto-filling CRM records, inferring firmographics for segmentation, or scoring inbound signups—decisions about whether enrichment happens at signup, on-demand, or in a nightly batch.
• Roadmap sequencing for sales/RevOps tooling: Because it targets Laravel 12/13 and PHP 8.2+, it fits only greenfield or recently upgraded services. That constrains where in the roadmap this ships and forces an explicit answer on whether the sales tooling lives in the modernized service or the legacy monolith.
• Pricing and margin modeling: Bulk enrichment is credit-metered at Apollo. The package exposes the capability; the PM owns the unit-economics decision (cache-once vs. re-enrich, enrichment caps per plan tier, which tier gets bulk vs. single).
• Data-compliance posture: Enrichment means ingesting third-party PII. Adoption forces a decision record on lawful basis, data retention, deletion propagation, and whether enriched fields are shown to end users or only used internally.

When to Consider This Package

Consider it when:

• You are on Laravel 12/13 with PHP 8.2+ (or can upgrade the service that needs it)—the stated support matrix is narrow and will not help a Laravel 9/10 estate.
• The product need is read-oriented B2B data: search, lookup, enrich. That is exactly the surface this covers.
• You want vendor calls wrapped, not scattered: if Apollo is a strategic vendor, centralizing it behind a package beats ad-hoc HTTP calls in controllers, and makes swapping providers a bounded change.
• You are already paying Apollo or are prepared to; the package adds no data of its own.
• Enrichment volume is low-to-moderate or cacheable—bulk endpoints exist, but cost scales with credits, not with your infrastructure.

Look elsewhere when:

• You need write-back or two-way sync (sequences, CRM push, contact creation/updates)—this release is search and enrichment only.
• You need other data categories (intent signals, technographics beyond org fields, job-change alerts) or a provider-agnostic aggregation layer; a dedicated enrichment router (Clearbit-alternatives, Clay-style orchestration) may fit better.
• You require audited enterprise guarantees: version 1.0.0 is a first release. Expect thin error taxonomy, undocumented rate-limit and retry behavior, and no track record on failure modes. For revenue-critical paths, budget for wrapping it or building the client in-house.
• Compliance cannot tolerate Apollo's sourcing model—verify provenance, opt-out handling, and DPA terms before committing, independent of the package.
• Your stack is not Laravel or is pinned to older PHP; the maintenance cost of an unofficial wrapper outweighs the convenience.

How to Pitch It (Stakeholders)

For executives: A small, low-cost integration that gives us Apollo.io's B2B people and company data inside our Laravel application—prospecting, record enrichment, and firmographic fill-in without building a data pipeline. It is a vendor dependency, so the real commitment is the Apollo contract, not the code. Treat v1.0.0 as an accelerator, not a platform: recommend a scoped pilot behind one feature flag, with credit spend capped and a compliance review of PII handling completed first. Success looks like measured enrichment hit-rate and cost-per-enriched-record, plus a clean answer to "could we swap providers in a sprint?"

For engineering: Thin Laravel wrapper over Apollo's search and enrichment endpoints—people search, org search, single and bulk people enrichment, org enrichment. Requires Laravel 12/13, PHP 8.2+. It is a 1.0.0, so assume incomplete handling of pagination edge cases, 429/5xx retries, and partial bulk failures; wrap it in our own adapter rather than calling it from controllers, and persist enrichment results with a TTL so we pay credits once. Add contract tests against the vendor sandbox so a provider-side change surfaces in CI, and keep the vendor call behind an interface so a second provider is a config change.

For sales/RevOps: Unlocks in-product list building and automatic contact/company enrichment for the accounts we already have. The tradeoff is per-record credit cost—agree upfront which workflows enrich automatically and which are user-triggered, and define what happens when a record's data goes stale or a contact exercises deletion rights.