EZWhatsApp Templates

Agency templates

Repeatable client workflows with explicit handoff rules.

These templates are implementation contracts for agencies. Each one states what to build, which EZWhatsApp API surface to use, how replies return to the client workspace, and what acceptance evidence proves the workflow works.

Shared rules for every template

Auth

Use the correct token family.

Automation sends use a line API token. Workspace actions use a workspace ID token. Do not mix them.

Idempotency

Every outbound action must be send-once.

Build idempotency keys from the client system event id, not from timestamps alone.

Replies

Replies must land in the workspace.

When an automation starts a conversation, the client team must be able to see and handle replies inside the shared inbox.

Evidence

Acceptance needs durable proof.

Use queued response ids, webhook deliveries, conversation ids, and visible workspace messages as proof. Screenshots alone are not enough.

E-commerce order updates

Build

Listen to Shopify, WooCommerce, ERP, or custom store events. Send transactional updates through POST /api/v1/messages/text or URL media through POST /api/v1/messages/media.

Client gets

Customers can reply to the same WhatsApp line. Replies become visible in the shared inbox for the client's team.

Idempotency-Key: order:{storeOrderId}:ready
{
  "to": "+972501234567",
  "body": "Your order {orderNumber} is ready for pickup.",
  "ctaUrlButton": {
    "displayText": "Open order",
    "url": "https://store.example.com/orders/{storeOrderId}"
  }
}
  • Acceptance: health check is sendable before the first send.
  • Acceptance: duplicate store event returns the same queued attempt or does not create duplicate customer messages.
  • Acceptance: customer reply appears in the workspace conversation.

Appointment reminders

Build

Use calendar, booking, or CRM events to queue reminder text. Use one idempotency key per appointment and reminder stage.

Client gets

Confirmations, cancellations, and reschedule requests return to the team inbox instead of being trapped in the automation tool.

Idempotency-Key: appointment:{appointmentId}:24h
{
  "to": "+972501234567",
  "body": "Reminder: your appointment is tomorrow at 10:30. Reply here if you need to reschedule."
}
  • Acceptance: reminder job does not send if the appointment was cancelled upstream.
  • Acceptance: duplicate job retries do not send duplicates.
  • Acceptance: reply webhook includes conversationId so the integration can reply in-thread if needed.

Lead handoff from forms or ads

Build

Capture qualified website form, ad lead, or landing-page data. Send the first WhatsApp follow-up through the line token, then let the client team take over inside EZWhatsApp.

Client gets

A visible conversation with customer context. The agency does not need to build a custom inbox for sales handoff.

Idempotency-Key: lead:{leadId}:first-touch
{
  "to": "+972501234567",
  "body": "Hi {firstName}, thanks for your interest. A team member will help you here."
}
  • Acceptance: source lead id is preserved in the agency system logs.
  • Acceptance: phone number is normalized before sending.
  • Acceptance: client can assign or claim the resulting conversation in EZWhatsApp.

CRM sync and customer context

Build

Use webhooks to receive inbound messages and status changes. Sync the conversation id, phone number, and relevant message metadata into the CRM.

Client gets

CRM visibility without moving WhatsApp ownership out of EZWhatsApp. EZWhatsApp remains the shared workspace for the team.

POST /api/v1/webhooks
{
  "targetUrl": "https://agency.example.com/ezw/webhook",
  "events": ["messages.post", "statuses.post", "chats.post"],
  "payloadFormat": "whapi",
  "enabled": true
}
  • Acceptance: webhook target rejects unauthenticated requests at the agency layer if the client requires it.
  • Acceptance: inbound payload stores conversationId when present.
  • Acceptance: CRM sync failure does not block EZWhatsApp inbox operation.

Campaign reply management

Build

Use the Platform customer-admin campaign surface for campaign workflows. Do not emulate campaigns by looping generic direct sends unless the product owner explicitly approves that scope.

Client gets

Replies routed back into the workspace, with operational visibility for the team.

  • Acceptance: imported recipients remain auditable back to the source upload or source system.
  • Acceptance: campaign replies become workspace conversations.
  • Acceptance: send pacing and suppression decisions are explicit, not inferred.

Support escalation

Build

Use webhooks to detect inbound messages that match agency-defined escalation rules. Notify the client team in their own system, then keep the conversation in EZWhatsApp.

Client gets

Urgent WhatsApp chats are surfaced faster without changing the source of truth for assignment, ownership, or conversation history.

Webhook event: messages.post
Agency action:
1. Validate X-EZW-Delivery-Id is new.
2. Read conversationId from payload if present.
3. Apply agency escalation rules.
4. Notify the client team.
5. If auto-replying, use conversationId with POST /api/v1/messages/text.
  • Acceptance: webhook retries are idempotent by X-EZW-Delivery-Id.
  • Acceptance: escalation notifications include the line id and conversation id.
  • Acceptance: support team can handle the chat in EZWhatsApp after notification.

Client handoff checklist

Area Handoff requirement Evidence
Auth Line token stored in the client/agency secret manager, not in tracked code. Secret path or deployment variable name, without exposing the value.
Health Automation checks /api/v1/health before production sends. Logged health response with sendable and state fields.
Idempotency Every outbound attempt has a deterministic idempotency key. Retry test proving no duplicate customer message.
Webhooks Webhook handler stores delivery ids and returns 2xx only after accepted processing. One inbound and one status event captured.
Workspace Client team knows where replies appear and how to claim or assign work. Visible conversation and client-side signoff.
Boundary Unsupported asks are recorded as decisions, not hidden in code. Scope note for campaigns, bots, CRM ownership, or compliance if relevant.