Scrapecreators Php Laravel Package

Product Decisions This Supports

• Feature roadmap: social-platform data features. 27 platform resources with 251 typed methods means we can ship features that depend on profile, content, comment, and search data across major social platforms without standing up our own scraping infrastructure. This directly enables social listening, influencer/creator discovery, competitor benchmarking, trend detection, UGC aggregation, and content analytics.
• Build vs. buy. The package moves "acquire social data" from a multi-quarter engineering program (proxies, anti-bot evasion, parser maintenance, per-platform schema drift) to a scoped integration with a credits-based vendor. Default position becomes buy to validate, build only where volume or differentiation justifies it.
• Time-to-market and validation. Because endpoints are generated from the vendor's OpenAPI spec, we can prototype a data-backed feature in days and test demand before committing to proprietary pipelines. cache_max_age plus isCached()/cachedAt() let us design features that stay credit-efficient at low volume.
• Cost-aware product design. creditsCharged() and creditsRemaining() on every response make per-call unit economics observable in-product; we can gate expensive endpoints, surface usage to customers, and model pricing tiers without guesswork.
• Reliability and UX decisions. The typed exception taxonomy (NotFoundException, RestrictedException with isAgeRestricted()/isPrivate(), UnavailableException, InsufficientCreditsException, RateLimitException, etc.) — including classification of HTTP 200 placeholder accounts — lets us build honest empty/restricted states instead of silently broken features.
• Use cases to prioritize: internal analytics dashboards, creator-marketing and influencer-vetting tools, social proof/content widgets, lead enrichment, and content moderation triage.

When to Consider This Package

Adopt when:

• The stack is Laravel/PHP and we want first-class integration (service provider, config, typed client) rather than hand-rolled HTTP glue.
• The roadmap depends on read access to multiple social platforms and speed to market beats owning the data pipeline.
• Expected volume is moderate and credit-based costs are acceptable relative to engineering cost of an in-house scraper.
• We value typed DX and a clean exception model — the generated 251-method surface and error hierarchy materially reduce integration and maintenance effort.
• We can tolerate vendor dependency and want to validate demand before building.

Look elsewhere / defer when:

• We need real-time streaming/firehose access, guaranteed SLAs, or enterprise contractual guarantees.
• Volume is high enough that per-call credits dominate unit economics versus a negotiated data provider or owned pipeline.
• We need write actions (posting, messaging) — this is a read/scrape client.
• Target platforms are not in the 27 covered, or compliance/legal review flags scraping-based sourcing for our jurisdiction or customer contracts.
• We need long-term API stability: this is 0.1.0, generated from a third-party spec, so method signatures and platform coverage can shift on regeneration. Pin versions and budget for upgrade work.
• Non-PHP services own the integration (the client is usable outside Laravel, but the provider/config value is Laravel-specific).

Adoption guardrails: wrap the client behind our own adapter/interface so a vendor swap or spec regeneration is contained; instrument credit spend from day one; confirm vendor terms of service and data-usage rights with legal before external-facing features.

How to Pitch It (Stakeholders)

To executives: This is a buy-not-build decision that compresses months of scraping-infrastructure work into a single integration. One package unlocks read access to 27 social platforms and ~250 endpoints, letting us ship and validate social-data features this quarter instead of next year. Costs are usage-based and visible per request, so we can price features and cap spend. Risk is contained: it's a 0.1.0 dependency behind our own adapter, so we can validate demand cheaply and revisit build-vs-buy once volume is proven.

To engineering: The package gives us a typed client generated from the vendor's OpenAPI spec, a Laravel service provider with publishable config, and a well-designed exception hierarchy (auth, rate limit, credits, not-found, restricted/private/age-gated, unavailable, invalid request/response) with the response and decoded envelope attached for debugging. Response exposes data(), dot-path get(), array access, and credit/cache metadata, so we get observability for free. Caveats: it's early (0.1.0), the surface regenerates from an external spec, and 200-status placeholders are classified heuristically — we should pin the version, wrap it behind an interface, and add contract tests around the edge cases we depend on.