Laravel Instantly Laravel Package

Product Decisions This Supports

• Build vs. buy for outbound tooling integration. This package lets you treat Instantly.ai as a capability layer inside your Laravel app instead of purchasing a separate orchestration tool (Zapier/Make/n8n) or hand-rolling an HTTP client. The decision it unlocks is "integrate directly via a thin wrapper" rather than "glue with no-code middleware."
• Roadmap: whether outbound/prospecting becomes a first-class product surface. Campaign, lead, account, analytics, and blocklist coverage is essentially the full CRUD surface for a cold-outreach motion. That is enough to justify a roadmap item like "sync product signups → sequenced outreach" or "in-app campaign management for customer-facing teams."
• Partner/agency packaging. accounts support implies multi-workspace management, which is the enabling primitive for agency or reseller models — one tenant per client, provisioned programmatically. Worth validating whether accounts here means sending mailboxes or client workspaces before committing to that roadmap bet.
• Analytics ingestion into internal reporting. The analytics resource supports pulling campaign performance into your own dashboards/warehouse rather than living in Instantly's UI — a decision about single source of truth for GTM metrics.
• Deliverability/risk posture. blocklist support is the compliance and sender-reputation control knob; it makes an automated "suppress on churn/bounce/complaint" decision feasible without manual ops.
• Feature scoping for v1 of an internal tool. Because the package is narrow and explicit about its resource coverage, it's cheap to timebox a spike and let the results decide whether to invest further, rather than committing to a bespoke integration project.

When to Consider This Package

Adopt when:

• You are already an Instantly.ai customer and the subscription is not in question. This package is a client, not a replacement.
• Your stack is Laravel/PHP and you want Composer-managed dependency hygiene, framework-native config, and no bespoke Guzzle wrapper to maintain.
• Your integration need maps to the five covered resources: campaigns, leads, accounts, analytics, blocklist. That covers lead ingestion, campaign lifecycle, and reporting sync.
• You can tolerate 1.0.0 risk: an initial release, pinned to Instantly's v1 REST API, with an unproven maintenance history and no stated deprecation policy.
• You are willing to wrap it behind your own interface (a small internal repository/service class) so a future swap to direct HTTP calls or a successor package is a one-file change.

Look elsewhere or defer when:

• You are not on Instantly, or are evaluating ESPs — this creates lock-in with no portability.
• You need capability not listed in the release: webhooks/event push, inbox or email-send endpoints, OAuth flows, or Instantly v2 endpoints. Absence from the release notes is not proof of absence, but it must be verified before you scope on it.
• You need vendor-backed SLAs, support contracts, or security review artifacts — assess the maintainer's track record first.
• Your workload is high-volume or rate-limit sensitive and would benefit from queueing, retry/backoff, and batching that a v1.0.0 wrapper likely does not yet provide.
• The team is not PHP/Laravel — a thin SDK offers no advantage over direct REST calls.

How to Pitch It (Stakeholders)

For executives: A small, low-cost PHP library that connects our existing Laravel product to Instantly.ai's outreach platform, covering campaigns, leads, accounts, analytics, and suppression lists. It converts an outbound motion from a manual, browser-based process into something our software can drive — which is the difference between "our sales team uses a tool" and "our product can run outreach for customers." Cost of evaluation is a short engineering spike; the strategic upside is a defensible GTM feature and a possible agency/reseller packaging path. Principal caveat: this is a brand-new 1.0.0 release against a v1 API, so we treat it as a timeboxed pilot behind an internal abstraction until we've validated maintenance cadence and endpoint coverage.

For engineering: Standard Composer dependency, framework-idiomatic configuration, and a resource-oriented surface (campaigns, leads, accounts, analytics, blocklist). Recommended integration is a thin adapter layer we own — our service classes call our interface, not the package directly — so we can swap to raw HTTP or a successor without touching call sites. Before committing: confirm authentication model and rate limits, verify whether webhooks and send/inbox endpoints exist outside this release, and check PHP/Laravel version constraints. Budget a spike that exercises the highest-value path end-to-end (lead create → campaign enroll → analytics read → blocklist add) rather than a full integration.

Ask: Approve one engineering spike to validate coverage and reliability; hold any commitment to shipped customer-facing functionality until that spike clears.