Larareact Laravel Package

Product Decisions This Supports

• Channel strategy: Commits to WhatsApp as a first-class notification/delivery channel rather than an ad-hoc script, enabling roadmap items around supplier and producer communications (e.g. carnet delivery) without a new vendor integration project per use case.
• Build vs. buy: The release supplies the "last mile" plumbing (multipart document send, MIME/size validation, JSON fallback, structured error logging) that teams typically underestimate. This shifts the decision from "build an integration" to "buy/borrow the integration and invest our effort in workflow and UX."
• Access control as a product requirement: Granular whatsapp.view / manage / send permissions plus sector mapping (Integraciones) make WhatsApp safe to expose to non-technical admins and to multi-role/multi-tenant customers. This unblocks enterprise or regulated buyers who require least-privilege access before enabling a channel.
• Phased rollout by role and segment: Because send rights are separable from configuration rights, we can launch in stages—ops team configures, a pilot group sends, then broaden to proveedores.* and productores.* audiences—without new engineering work.
• Reliability investment is now measurable: Documented fallback behavior and improved error payloads (HTTP code + response body) give us the observability needed to set SLOs (delivery success rate, failure reasons) and to decide whether to keep the fallback path or retire it.
• Roadmap sequencing: Security and permission hardening shipped ahead of new features, which supports prioritizing "safe to operate" work before expanding scope (e.g. templates, media types, inbound webhooks).
• Documentation as a shippable artifact: Corrected endpoint list (removing the 404 send-image path) reduces support load and shortens onboarding for integrators—relevant when deciding whether to expose this to partners.

When to Consider This Package

Consider it when:

• The product is a Laravel application already using spatie/laravel-permission and an existing admin UI with module/sector grouping—the seeder and sector-mapping changes slot in directly.
• The primary need is outbound WhatsApp messaging, including document/PDF delivery (carnets, invoices, tickets), at modest volume where a synchronous request-plus-fallback is acceptable.
• You want role-gated configuration (who can view vs. manage credentials vs. send) without designing a permission taxonomy from scratch.
• Your team is small and would rather adopt working integration code plus documented endpoints than build multipart handling, MIME validation, and retry/fallback logic.
• The context is an internal or single-tenant operational tool where tight coupling to one app's route names and permission strings is acceptable.

Look elsewhere when:

• You need provider abstraction (Meta Cloud API, Twilio, 360dialog) or multi-channel messaging—this is single-provider and app-specific.
• You require a stable public package API with semantic versioning guarantees: routes, permission names, and WhatsAppService are coupled to one application's conventions, and permission strings are effectively a breaking surface.
• You need high throughput, queuing, rate-limit handling, or delivery webhooks/receipts—none of that is evidenced here.
• You are not on Spatie permissions, or your admin UI expects a different permission/sector model.
• You need verified test coverage and CI evidence; the release describes manual verification steps (php artisan test, permission lookup, manual send) rather than a documented automated suite for the new service.
• Secret/credential lifecycle matters more than configuration CRUD (rotation, vault storage, audit trail) — token generation is present, but rotation/audit guarantees are not stated.

How to Pitch It (Stakeholders)

For executives (one paragraph): This release makes WhatsApp a supportable product capability rather than a one-off script. It adds role-based access so only authorized staff can configure the channel or send documents, fixes a reliability defect in document delivery, and documents the endpoints we actually support. The business payoff is faster enablement of supplier and producer communications with clear accountability and lower support burden—achieved with incremental effort instead of a new integration project. The main caveat is that the code is tailored to our application's conventions, so it is an accelerator, not a vendor-independent platform bet.

For engineering leads: You get a WhatsAppService that uses the correct multipart document field, validates MIME type and file size, logs HTTP status and response body on failure, and falls back to JSON when multipart fails. Routes are named consistently under integrations.whatsapp.*, protected by auth + verified plus per-route can() checks, and the seeder maps whatsapp.* into the Integraciones sector. Two requests before adoption: (1) confirm automated tests cover the multipart/fallback paths and MIME rejection, not just a manual smoke test; (2) treat permission names and route names as a public contract—changing them later breaks roles and UI, so version them deliberately. Also confirm how credentials are stored and rotated, since token generation alone is not a lifecycle story.

For product/ops stakeholders: After rollout, an admin with whatsapp.manage sees Integraciones → WhatsApp, can connect/disconnect/reconnect, and check status; staff with whatsapp.send can message and send carnets, while proveedores.send-carnet-whatsapp and productores.send-carnet-whatsapp scope that ability to the right teams. Expect fewer "it didn't send" escalations because failures now log a reason we can act on, and expect a short enablement period while roles are assigned.