We've launched Rich Communication Services (RCS) messaging with intelligent SMS fallback and enhanced delivery tracking.

✅ What's New

POST /v2/rcs
A powerful new API endpoint for sending rich, interactive messages via RCS with automatic SMS fallback capabilities.

Key features:

• Dual Message Types:
  Send Basic RCS messages (160 characters, SMS format) or Simple RCS messages (3072 characters with full UTF-8 and emoji support).

• RCS Agent-Based Delivery:
  Messages are sent through registered RCS Agent IDs rather than phone numbers, providing better brand identity and compliance with RCS standards.

• Intelligent SMS Fallback (optional):
  Include an SMS fallback message that automatically delivers if the recipient's device doesn't support RCS or if carrier delivery fails.

• Enhanced Webhook Support:
  Track message delivery with RCS-specific webhook events including RCS_STATUS with statuses: SENT, DELIVERED, FAILED, and READ (unique to RCS).

• Message Tracking via message_ref:
  Tag each message with a custom message_ref—this ID will be included in delivery webhooks, making it easy to track message delivery status in your systems.

• Traffic Type Classification:
  Specify message traffic types (authentication, transaction, promotion, serviceRequest, acknowledgement) for better carrier routing and compliance.

Clean and Compliant Formatting:

• All phone numbers must be in E.164 international format.
• RCS Agent IDs must be pre-registered with your account.
• Currently available for Australian recipients.

🎯 Key Benefits

• Rich Messaging: Send longer messages with emoji and UTF-8 support
• Read Receipts: Know when recipients actually read your messages (RCS-specific feature)
• Intelligent Fallback: Ensure message delivery even to non-RCS devices
• Brand Identity: Use registered RCS Agent names instead of phone numbers

🔧 Technical Details

Request Format

{
  "sender": "DemoSender",
  "recipient": "+447903749662",
  "content_type": "text",
  "content": {
    "text": {
      "message": "Hi Michael,\nJust a quick reminder. You are amazing!!\nReply STOP to opt out."
    }
  },
  "sms_fallback": {
    "message": "Hi Michael, just a quick reminder. You are amazing!! Reply STOP to opt out."
  },
  "message_ref": "order-12345"
}

Response Format

{
  "data": {
    "id": "6fdae71c-dad7-4c36-9734-a69693ecf3b4",
    "message_ref": "order-12345",
    "sender": "DemoSender",
    "recipient": "+447903749662",
    "message_traffic_type": "default",
    "content_type": "text",
    "content": {
      "text": {
        "message": "Hi Michael,\nJust a quick reminder. You are amazing!!\nReply STOP to opt out."
      }
    },
    "created_at": "2025-01-07T05:16:07Z"
  }
}

Webhook Support

RCS webhooks include the new RCS_STATUS event type with enhanced status tracking:

{
  "event_type": "RCS_STATUS",
  "timestamp": "2025-01-07T05:16:07Z",
  "webhook_id": "fd0e6485-b905-44c1-bd55-fee1d0d6d864",
  "webhook_name": "RCS Status Webhook",
  "status": {
    "type": "RCS",
    "id": "6fdae71c-dad7-4c36-9734-a69693ecf3b4",
    "message_ref": "order-12345",
    "recipient": "+447903749662",
    "sender": "DemoSender",
    "status": "READ"
  }
}

🚀 Getting Started

1. Contact Support: Reach out to register your RCS Agent ID
2. API Integration: Use the new /v2/rcs endpoint
3. Webhook Setup: Configure webhooks to track RCS_STATUS events
4. Test Messages: Start with Basic RCS messages, then explore Simple RCS features

📋 Message Types Comparison

💬 Questions or Need Help?

Ready to start sending RCS messages? Contact our support team to get your RCS Agent registered and begin integrating this powerful new messaging channel into your applications.

We’re introducing enhanced webhook subscriptions that allow for more granular filtering, reducing unnecessary noise and improving third-party integrations.

🎯 Key Features

When creating a new webhook, you can now provide filters on the following fields:

Event Type (e.g. LINK_HIT, SMS_INBOUND)

Sender (e.g. 61400000000)

Message Reference (e.g. msg_abc)

Status (e.g. DELIVERED)

🧠 Filter Logic

Within each individual filter field, multiple values are combined with OR logic.
Example:
event_type == LINK_HIT OR event_type == SMS_INBOUND

Across different filter fields, conditions are combined with AND logic.
Example:
(event_type == LINK_HIT OR SMS_INBOUND) AND sender == 61400000000

🔍 Context-Sensitive Filtering

The filters are applied differently based on the event type:

• For status events (SMS_STATUS, MMS_STATUS, etc.):
  sender, status, and message_ref filters are applied to the status payload.

• For LINK_HIT events:
  sender and message_ref filters are applied to the source_message in the link hit payload.

• For OPT_OUT events:
  sender and message_ref filters are applied to the source_message in the opt-out payload.

• For inbound events (SMS_INBOUND, MMS_INBOUND, etc.):
  sender and message_ref filters are applied to the last_message in the inbound payload.

🚨 Legacy Support

You can still use the existing webhook creation format for now, but it will be deprecated in a future release.

🆕 New Webhook Request Format

{
  "name": "Webhook test name",
  "url": "https://webhook.site/test",
  "rate_limit": 100,
  "filter": {
    "event_type": ["LINK_HIT"],
    "sender": ["61400000000"],
    "message_ref": ["msg_abc", "message_cdf"],
    "status": ["DELIVERED"]
  }
}

✅ New Webhook Response Format

{
  "id": "23f4692f-34e0-4931-90b9-50b5a527495a",
  "name": "My Webhook",
  "url": "https://sms-kudosity-webpage-example.glitch.me/message",
  "rate_limit": 0,
  "filter": {
    "event_type": ["LINK_HIT"],
    "sender": ["61412345678"],
    "status": ["DELIVERED"],
    "message_ref": ["msg_xyz789"]
  },
  "created_at": "2024-11-19T05:55:06.810258960Z",
  "updated_at": "2024-11-19T05:55:06.810258960Z"
}

🛠 Minor Changes

📅 Timestamp Format Update

We are slightly modifying the datetime format used in the webhook API.

Why this matters:
Both formats conform to RFC 3339, a subset of ISO 8601.
This change removes nanosecond precision (9 digits) in favor of microsecond precision (6 digits).
Most datetime parsers will handle this gracefully unless you are doing exact string matching or have schema constraints.

🆕 webhook_id and webhook_name in Payloads

We’ve added two new fields to webhook payloads for better traceability:

{
  "event_type": "WHATSAPP_STATUS",
  "timestamp": "2025-05-02T01:57:54Z",
  "webhook_id": "21153c94-4e75-4c79-bed4-1398f8c00e8b",
  "webhook_name": "PJ WA Status",
  "status": {
    "id": "f22625c4-647f-4e32-86af-9eed4bc064e7",
    "type": "WHATSAPP",
    "message_ref": "optional-ref-12",
    "sender": "61423411111",
    "recipient": "61457577729",
    "status": "SUBMITTED"
  }
}

These are non-breaking additions and should not affect existing integrations unless strict schema validation is enforced.

💬 Questions or Concerns?

If you anticipate issues (e.g., due to schema validation), please contact us — we're happy to work with you on a solution.

We’ve just launched a brand new endpoint to support templated notification messages via WhatsApp using registered WhatsApp Business accounts.

✅ What’s New

POST /v2/whatsapp
A robust API endpoint for sending pre-approved templated messages to users on WhatsApp.

Key features:

• Template-Based Messaging:
  Send messages using WhatsApp-approved templates. Each template must be pre-configured in your WhatsApp Business account and supports text-based dynamic parameters.
• SMS Fallback Support (optional):
  Include an SMS fallback message that gets delivered if the WhatsApp message fails.
• Message Tracking via message_ref:
  Tag each message with a custom message_ref—this ID will be included in delivery webhooks, making it easy to track message delivery status in your systems.
• Locale-Specific Messaging (optional):
  Customize the message by specifying a locale (e.g., en_US, pt_BR) to reach users in their preferred language.

Clean and Compliant Formatting:

• All phone numbers must be in E.164 international format.
• Templates must adhere to WhatsApp’s strict format and approval process.