Php Api Client Laravel Package

Product Decisions This Supports

• Form protection strategy: Deciding whether to add server-side spam verification to public forms (contact, registration, password reset, comments, checkout, support) using a self-hosted, privacy-oriented alternative to reCAPTCHA/hCaptcha.
• Build vs. buy/use: Choosing the official PHP client over a custom Guzzle integration for mosparo. The package handles tokens, request signing, error cases, and typed result objects; custom code would recreate that surface and need ongoing maintenance.
• Privacy and compliance roadmap: Supporting GDPR/privacy reviews by reducing dependency on third-party CAPTCHA vendors that may set cookies, track users, or transfer data outside the organization.
• Laravel integration planning: Informing whether to wrap the client in a Laravel validation rule, form request, or dedicated verification service. The package is framework-agnostic, so Laravel-specific glue is a small internal build decision.
• Operational ownership: Forcing an explicit decision about hosting and maintaining a mosparo instance, including uptime, upgrades, key management, and fail-open vs. fail-closed behavior when verification is unavailable.
• Analytics and admin features: Enabling spam/valid submission statistics in internal dashboards via the statistics API, if the product needs form-abuse reporting.
• Rule package workflows: Relevant only for products that distribute or consume mosparo rule packages; most teams will not need the rule package APIs.
• Vendor/dependency risk: The client is official but has very low visible adoption (5 stars, 0 dependents). This supports a pilot-first decision rather than broad platform standardization.

When to Consider This Package

Consider it when:

• You run a PHP 8.1+ or Laravel application with public-facing forms that need spam protection.
• You already operate, or are willing to operate, a mosparo 1.5+ instance.
• You need server-side verification of submitted form data, not just client-side widgets.
• Privacy, self-hosting, or avoiding third-party CAPTCHA tracking is a real product requirement.
• You want the official client rather than maintaining your own mosparo API integration.
• You need mosparo statistics or rule package management in addition to basic form verification.

Look elsewhere when:

• You do not want to host and operate mosparo; a managed CAPTCHA/spam service is a better fit.
• You need enterprise SLAs, commercial support, or a large ecosystem with proven adoption.
• Your stack is not PHP/Laravel, or you need edge/async verification outside a PHP request lifecycle.
• Your forms are low-risk and a honeypot, rate limiting, or moderation queue is sufficient.
• You need a Laravel-native package with a service provider, config publishing, and Blade components out of the box; this client is a thin library and would require internal glue.
• You cannot tolerate the operational failure mode of a self-hosted verification dependency, unless you explicitly design fail-open behavior and monitoring.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed PHP client for mosparo, an open-source, self-hosted spam protection system. It supports a privacy-friendly alternative to reCAPTCHA/hCaptcha: no per-request fees, no third-party tracking dependency, and control over form submission data. The trade-off is operational ownership of a mosparo instance. Recommend a contained pilot on one or two high-volume forms before platform-wide adoption, with clear success metrics: spam reduction, false-positive rate, verification latency, and ops effort.

For engineering: The package is a thin, official API client. It verifies submissions with submit/validation tokens, returns typed results (isSubmittable(), isValid(), issues, verified fields), supports metadata storage, statistics, and rule package APIs. Integration is a Composer dependency plus a service/validation wrapper; no Laravel service provider is included. Engineering should decide fail-open vs. fail-closed behavior, timeout/retry policy, key storage, and whether verification belongs in a form request, validation rule, or dedicated service. Low adoption signals mean we should pin versions, monitor releases, and keep the integration isolated behind an internal interface.

For security/legal/ops: The main appeal is reduced third-party tracking and data minimization. The main risks are self-hosting burden, single-maintainer/early-ecosystem risk, and availability of the mosparo instance during form submission. Pair it with rate limiting, honeypots, and moderation rather than treating it as a complete abuse-prevention program.