WhatsApp Business API for team broadcast — create whatsapp group

Use case overview

This scenario uses the groups API with a create operation to provision a named WhatsApp group for team broadcasts. No 24-hour session window is required because the call is a channel management action.

Template example

Internal group created for sales broadcast — share the invite link with your team.

When to use it

Reach for this when sales or marketing needs a dedicated WhatsApp group for internal broadcast and campaign coordination, and creating groups by hand in the Business app does not scale across channels or automation. It fits developers wiring CRM or admin triggers, small teams standing up a named broadcast channel, and agencies provisioning client campaign groups without manual admin steps.

Workflow

1. Trigger

   An admin or CRM event triggers team group provisioning.

   event · triggered

2. Capture event

   groups create sets the group name and internal broadcast description.

   POST /groups

3. Build & send

   The API returns group metadata including the invite link.

   POST /groups

4. Delivered

   Your system shares the invite URL with authorised team members.

   delivered

Technical implementation

Prerequisites

1. 1MSG API Key · How to get API Key
2. WhatsApp Business account · How to Connect WABA
3. Open 24-hour session window · How the 24-hour window works
4. Customer opt-in · How to Manage Customers Consent

Code examples

#!/usr/bin/env bash
set -euo pipefail

# === Configuration (replace "___" placeholders) ===
API_BASE_URL="https://api.1msg.io"        # production 1MSG API base URL
CHANNEL_ID="___"                           # channel ID from 1MSG dashboard
API_TOKEN="___"                            # channel JWT token (Bearer)



URL="${API_BASE_URL%/}/${CHANNEL_ID}/groups"

read -r -d '' PAYLOAD <<JSON || true
{
  "groupName": "Sales team Q1",
  "description": "Internal broadcast"
}
JSON

RESPONSE="$(curl -s -w '\n%{http_code}' -X POST "$URL" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${API_TOKEN}" \
  -d "$PAYLOAD")"

HTTP_CODE="$(printf '%s' "$RESPONSE" | tail -n1)"
BODY="$(printf '%s' "$RESPONSE" | sed '$d')"

case "$BODY" in
  *'"created":true'*) ok=1 ;;
  *) ok=0 ;;
esac

if [ "$HTTP_CODE" -ge 200 ] && [ "$HTTP_CODE" -lt 300 ] && [ "$ok" -eq 1 ]; then
  echo "$BODY"
else
  echo "$BODY" >&2
  exit 1
fi

Response and delivery status

HTTP 2xx and JSON "sent": true mean 1MSG accepted the message for sending — not that it already reached the customer's phone. Save the id field (looks like wamid.…) to correlate delivery callbacks.

{
  "sent": true,
  "id": "wamid.HBgLMzgwNjM5...",
  "message": "Message accepted for delivery"
}

Delivery itself arrives later, as a separate callback. Register a webhook (POST …/webhook) and 1MSG POSTs status updates to your HTTPS endpoint in a top-level hooks[] payload.

{
  "hooks": [
    {
      "id": "gBGGeSaGViBfAgnlzOSHEwK9O6F",
      "type": "message",
      "status": "sent",
      "timestamp": "1654864094",
      "recipient_id": "556123122026"
    }
  ]
}

If you would rather not receive callbacks, poll GET {base}/{channel}/hookInfo?messageId=<id> instead. In practice delivery often completes within seconds — but the API contract does not guarantee it, so never block a flow waiting on it.

Common errors

FAQ