Meta Conversions Api Php Sdk Laravel Package

Technical Evaluation

• Architecture fit: The SDK is framework-agnostic and fits Laravel as a Composer dependency, not as a Laravel-native package. Expect to add a small application adapter/service that maps Laravel domain events to SDK User/Event objects, reads pixel ID/access token from config/secrets, and owns logging, retry, and queueing. It requires PHP 8.1+ and a PSR-18 HTTP client with PSR-17 factories; Laravel’s HTTP client is not PSR-18, so a Guzzle/Symfony adapter is likely needed.
• Integration feasibility: Feasible for a scoped server-side Meta Conversions API integration. v2.0.0-beta.3 tightens type safety: Fbp::$randomNumber is private, User::$fbc/$fbp are typed as Fbc|string|null, withCreationTime() accepts int|\DateTimeInterface, and fluent methods declare static returns. Coming from beta.2, most apps are unaffected unless they directly mutated randomNumber, assigned invalid Fbc/Fbp values (now TypeError), or caught InvalidArgumentException from withCreationTime(). Coming from 1.x, follow UPGRADE-2.0.md.
• Technical risk: This is still beta software. The known multi-pixel limitation is operationally significant: if Meta rejects one pixel, the client throws and remaining pixels are not attempted; the exception type may change before 2.0 stable. TypeError is PHP’s programming-error type and does not implement ExceptionInterface, so exception handling must account for it. The SDK is synchronous and external-dependency-heavy, and provides no Laravel service provider, facade, or config lifecycle.
• Key questions: Is this intended for production now or a pilot? How many pixels are involved, and must every pixel receive every event? What event volume and latency budget? What deduplication strategy will be used (event_id)? What is the consent/privacy policy for server-side events? Which PSR-18/17 implementation will be bound? What queue/retry/alerting policy applies? Should the beta be pinned exactly or allowed via ^2.0@beta?

Integration Approach

• Stack fit: Laravel app on PHP 8.1+ with Composer and PSR-18/17 adapters. Add configuration for pixel ID(s), access token, test mode, and timeouts; wrap the SDK in an application service or queued job; map Laravel domain events to Meta CAPI payloads. Avoid scattering direct SDK calls through controllers.
• Migration path: From 1.x, use UPGRADE-2.0.md, validate payload mapping, stricter types, and exception handling. From beta.2, usually no change unless accessing Fbp::$randomNumber directly, assigning non-Fbc/Fbp/string/null values to User::$fbc/$fbp, or relying on withCreationTime() throwing InvalidArgumentException.
• Compatibility: No Laravel version constraint beyond PHP 8.1+ and PSR-18/17; verify against the app’s chosen HTTP client and adapter. Composer stability must permit the beta (^2.0@beta) or pin an exact beta version. No framework lifecycle hooks are provided.
• Sequencing: Confirm Meta CAPI requirements and pixel/token ownership; add dependency and PSR adapters; build config and adapter; unit-test with a fake PSR client; send staged test events; move dispatch to queued jobs; add monitoring; then production. If multiple pixels are critical, plan per-pixel calls or compensating retries because one rejection can stop remaining pixel attempts.

Operational Impact

• Maintenance: Beta status requires active release tracking and disciplined composer.lock management; exception behavior may still change before 2.0 stable. Stricter types reduce bad-state bugs but can surface TypeErrors after upgrades. Keep the SDK behind an internal wrapper to isolate future changes.
• Support: SDK support is via Setono’s GitHub; Laravel integration, secrets rotation, HTTP client configuration, queueing, retries, consent handling, and monitoring remain internal responsibilities. Document the multi-pixel limitation and a support runbook.
• Scaling: Do not call the Meta API synchronously in user-facing requests at volume. Use queued jobs with timeouts, backoff, rate-limit handling, and idempotency/deduplication. Send per pixel separately if the business requires attempting all pixels, since one rejected pixel can prevent remaining sends.
• Failure modes: Network/PSR client errors, Meta authentication or event rejection, rate limiting, invalid payloads, TypeError from invalid assignments, and partial multi-pixel failure. Log correlation IDs and event_id, track delivery outcomes, and alert on failure spikes.
• Ramp-up: Low-to-moderate for a Laravel developer familiar with Composer and PSR interfaces; moderate for Meta CAPI semantics, consent, deduplication, and multi-pixel reliability. Provide internal examples for config, event mapping, queueing, and exception handling.