Configure Laravel without exposing API keys
RelayWA is a QR-linked WhatsApp Web API, not Meta’s official Cloud API. Create a RelayWA workspace and connect a WhatsApp session by QR code. Create a session API key and add RELAYWA_API_BASE=https://relaywa.com/api and RELAYWA_SESSION_KEY to a server-only .env file. In config/services.php, define a relaywa array for URL, session key, and webhook secret.
Do not invoke RelayWA directly from a Blade template or a public frontend. A service class makes the HTTP behavior auditable and testable. Laravel 11/12 HTTP clients can use the built-in Illuminate HTTP facade without an unofficial RelayWA PHP SDK.
'relaywa' => [
'url' => env('RELAYWA_API_BASE', 'https://relaywa.com/api'),
'session_key' => env('RELAYWA_SESSION_KEY'),
'webhook_secret' => env('RELAYWA_WEBHOOK_SECRET'),
],Send a transactionally meaningful notification
The included RelayWaOrderNotifier sends an order-ready update via Http::withToken(...)->post(...). Supply the international destination without plus signs or spaces and create a stable clientMessageId from the order and event type, not a new random value on each attempt.
Trigger the notifier only after the order has reached the required business state and the recipient has opted in. In your own application, enqueue an after-commit job and pace jobs to prevent burst sends. RelayWA dispatches immediately; it rejects scheduledAt, priority, and maxAttempts.
return Http::withToken(config('services.relaywa.session_key'))
->timeout(30)
->post(config('services.relaywa.url').'/send-message', [
'to' => $recipient,
'text' => 'Your order is ready.',
'clientMessageId' => 'order-'.$orderId.'-ready-v1',
]);Protect the webhook with HMAC and event deduplication
RelayWA posts an event body with id, type, sessionId, createdAt and data fields. Its webhook signature is sha256=HEX over timestamp + a period + the exact raw body bytes. Read Request::getContent() before JSON parsing and use hash_equals on the computed signature.
The example controller checks timestamp age and uses Cache::add as a short-lived illustration of duplicate detection. For production, write event IDs into a database table with a unique index, persist payloads transactionally and dispatch processing jobs after commit. Cache::add by itself does not guarantee durable once-only processing.
$raw = $request->getContent();
$expected = 'sha256='.hash_hmac('sha256', $timestamp.'.'.$raw, $secret);
if (! hash_equals($expected, $signature)) {
return response()->json(['error' => 'Invalid signature'], 401);
}Test network uncertainty and production behavior
For a business notification workflow, cover consent checks, 401/403/409 responses, an HTTP timeout after a potentially accepted send, duplicate business events, invalid HMAC, stale timestamps and duplicate webhook IDs. The sample PHP service and controller are implementation templates; run your Laravel HTTP::fake and feature tests in your own Laravel app before deploying.
If sending returns an uncertain outcome, inspect the message status and reuse the original clientMessageId rather than creating another notification. A successful transport response is not proof the recipient saw the message. For endpoint reference and troubleshooting, use RelayWA’s existing /api-docs and /help pages.
- Keep secrets in server configuration, never screenshots or source control
- Do not confuse outbound app-managed retry policy with webhook delivery retries
- Get real customer opt-in and do not send spam or unsolicited promotions