Weave Code
Wapi Gateway Laravel Package
funnelchat20/wapi-gateway
Laravel/PHP package that provides a gateway to the WAPI WhatsApp API, helping you send messages, manage instances, handle webhooks, and centralize API configuration. It offers a simple, configurable interface for building WhatsApp automation and notifications in your applications.
Wapi Gateway is a Laravel package that integrates your application with the WhatsApp API gateway, giving you a clean, framework-native way to send messages and manage conversations without hand-rolling HTTP calls. It wraps the gateway's endpoints behind a simple, testable interface so you can focus on your product instead of boilerplate.
- Configurable credentials and base URL via Laravel config
- Fluent client for sending text and media messages
- Laravel-ready service provider and facade bindings
- Typed responses with clear error handling
- Easy to extend for custom gateway endpoints
Frequently asked questions about Wapi Gateway
- What is funnelchat20/wapi-gateway used for in a Laravel app?
- It is a Laravel package that wraps a WhatsApp API gateway so you can send messages, receive and process incoming webhooks, and manage WhatsApp sessions directly from your existing Laravel codebase. It exposes a service-style ZApiClient with a lighter inherited ZApiLite variant, so the same interface covers both full and minimal consumers. Typical uses include transactional notifications, support inbox integrations, and session lifecycle operations such as logout and unsubscribe.
- How do I install and configure funnelchat20/wapi-gateway with Composer?
- Install it with composer require funnelchat20/wapi-gateway, publish any package configuration your application needs, and add your gateway credentials to the environment. Because it is a service-style client, you resolve ZApiClient or ZApiLite from the container and inject it wherever you send messages or manage sessions. No queue, cache, or driver changes are implied by the package.
- Which Laravel and PHP versions does wapi-gateway support?
- The package follows standard Laravel package conventions and targets conventional Laravel applications, but you should confirm the exact PHP and illuminate/support constraints in its composer.json before installing. If you are on an older Laravel release, verify the constraint range actually covers your version instead of assuming it does. Patch releases such as 0.22.x are additive and do not introduce new dependencies.
- How do I handle incoming WhatsApp webhooks with this package?
- Incoming WhatsApp events arrive as webhooks, so you route them to a controller or handler that runs your own application logic. The package gives you a consistent PHP interface for that flow instead of hand-rolling raw HTTP handling, and request activity is recorded to device_logs through logRequest(). Keep the webhook endpoint outside CSRF protection and validate the payload before acting on it.
- How can I test message sending and webhook handling without hitting the real WhatsApp API?
- Use Laravel's HTTP fake or a Guzzle mock handler to stub gateway responses so your test suite never calls the live WhatsApp API. Assert that outgoing requests carry the expected payload and that webhook handling produces the expected domain changes. This also lets you verify that device_logs rows are written without depending on external service availability.
- What changed in unsubscribe() logging in v0.22.7?
- In v0.22.7 unsubscribe() now routes through the same logRequest() chokepoint as logout(), so every unsubscribe attempt leaves a durable record in device_logs. Previously the unsubscribe path, which fans out to a disconnect call and an integrator cancel call, bypassed logging entirely, meaning a paid instance could be billed without being cancelled and leave no trace. The new record includes a step discriminator of disconnect or cancel.
- Do I need a database migration to upgrade for the new unsubscribe log step?
- That depends on how step is stored: if it is a new column on device_logs, a package migration ships with the bump and must run in the same deploy; if it is a key inside an existing serialized payload, no migration is needed. Confirm the schema before deploying rather than assuming, because a strict schema will reject the new key. ZApiLite consumers need no code changes either way, since the behavior is inherited from the base class.
- Is upgrading from ^0.22.4 to ^0.22.7 backward compatible?
- Yes, v0.22.7 is described as additive and backward compatible at patch level, with no public API signature changes, no new dependencies, and no config publish or credential rotation required. Bump your Composer constraint to ^0.22.7 and update the package. The realistic breakage is downstream: dashboards, ETL, or alerting that assume a closed schema or a method allowlist may not tolerate new method=unsubscribe rows and the unfamiliar step key.
- Are WhatsApp tokens and credentials masked in the device_logs entries?
- sanitizeUrl() masks token segments in the /token/<token>/ path form, so unsubscribe URLs persisted in device_logs are sanitized today. That is a heuristic rather than a guarantee: if Z-API moves the token into a query string, a header, or a differently segmented path, tokens could begin landing unmasked in device_logs. Because unsubscribe URLs are now persisted where they previously were not, review the masking rules and treat this as a secret-hygiene control.
- Can a logging failure break unsubscribe, and will retries create duplicate log rows?
- Confirm that logRequest() runs safely inside the unsubscribe path and that the call is wrapped so a logging exception can never convert a successful cancel into a thrown failure. Also check idempotency: unsubscribe() should be safe to retry, and unless attempts are de-duplicated each retry will create a new device_logs row. Two extra rows per attempt is negligible per event, but those records now hold operational failure data that support and finance may want retained longer than generic request logs.
Weaver
How can I help you explore Laravel packages today?