Sdk Laravel Package

Product Decisions This Supports

• Build vs. buy for social and messaging surface area. v0.3.0 covers an unusually wide swath of networks in a single package — Meta (Facebook/Instagram/Messenger), Telegram, Slack, Discord, WhatsApp Business, Reddit, Snapchat, Google Business Profile, TikTok, and Google Ads/Meta Ads — plus a connected-site blogs resource. For a PM, this collapses dozens of distinct "build an integration" roadmap items into one adoption decision and one dependency.
• Whether to ship a unified inbox as a feature. Inbox actions, comment moderation status, reviews threads with ratings, Reddit inbox voting, and a chat adapter (per the README note) make a cross-network inbox a viable, near-term roadmap item rather than a multi-quarter investment.
• Ads management as a product line. Meta Ads depth (catalogs, reach & frequency, ad archive, account settings), a Google Ads surface with recommendations and optimization score, and TikTok ads (identities, Spark ads, conversions, ad comments) support decisions about whether ads tooling is in scope for the next planning cycle.
• Content marketing / SEO roadmap. Blog articles, goal-driven keyword planning, article approval, and products-on-connected-site features inform whether to build an owned "content engine" rather than integrating yet another CMS.
• Analytics and reporting roadmap. Per-network metric sets, content decay, posting cadence, post timelines, and native posts give a defensible starting point for reporting features without standing up your own data pipeline per network.
• Lifecycle messaging roadmap. Broadcasts and drip sequences, WhatsApp Business connections, and a Telegram bot open the door to messaging/automation features that would otherwise be separate product bets.
• Platform governance and trust. A security audit log / activity resource, account reconnect flags, and a webhook verifier support decisions about enterprise-readiness, compliance, and incident response requirements.
• Ops and media pipeline decisions. Direct media upload plus upload size limits matter for storage strategy, CDN choices, and the cost model of user-generated media.

When to Consider This Package

Consider adopting when:

• You are building (or extending) a Laravel/PHP product that needs multi-network social publishing, engagement, or ads coverage and you want to avoid becoming an OAuth/API-maintenance shop.
• Time-to-market dominates: a broad feature surface (inbox, ads, blogs, messaging, analytics) is more valuable than depth in any one area right now.
• You can tolerate pre-1.0 churn. v0.3.0 arriving after v0.2.0 with this many additions signals rapid, additive iteration; expect naming and behavior to shift before 1.0.
• Your product is comfortable delegating the network layer to the Fopost platform — this package is a client for that service, not a standalone integration library.
• You need capability breadth as a negotiating or discovery tool — shipping a thin cross-network feature quickly to validate demand before investing in bespoke integrations.

Look elsewhere when:

• You need deep, bespoke optimization in a single network (e.g., advanced bidding strategy, custom attribution) that a general-purpose wrapper won't expose.
• Vendor lock-in to the Fopost platform is unacceptable; the value here is coupled to that backend.
• You require a stable, semver-guaranteed API — pre-1.0 with this velocity is a poor fit for a long-lived platform commitment without abstraction.
• Your stack is not Laravel/PHP, or your team would rather own thin, typed network SDKs directly.
• You need SLA/enterprise support guarantees that an early-stage package can't yet evidence.

How to Pitch It (Stakeholders)

To executives: This release turns a long list of "someday" integrations into a single dependency. One adoption decision replaces an estimated multi-quarter effort to build and maintain publishing, inbox, ads, messaging, and reporting connectors across ten-plus networks. It's a credible path to faster time-to-market and lower integration maintenance cost, with the trade-off of a pre-1.0 dependency on one vendor.

To engineering: The package maps cleanly onto Laravel conventions and covers resources, models, and webhook verification out of the box. The caution is maturity: v0.3.0 is a large additive jump (accounts, ads, inbox, blogs, knowledge, activity) with no visible deprecation or breaking-change notes in the changelog. Recommend wrapping it behind our own internal interface so we can absorb churn before 1.0 and swap implementations if needed.

How to frame the ask: Propose a time-boxed spike — adopt behind an abstraction layer, ship one vertical slice (e.g., unified inbox or a single-network publishing flow), and re-evaluate at 1.0 for a broader commitment. This buys optionality and validates the build-vs-buy thesis cheaply.

Risks to disclose: pre-1.0 API instability, concentration on a single vendor/platform, and unproven depth in any one network versus dedicated SDKs.