RCS with automatic SMS fallback (delivery updates, payment reminders)
Using Kudosity as an MCP tool inside Claude, Cursor, and Windsurf
Each example keeps the API call visible so you can drop it straight into your own agent or workflow. Base URL https://api.transmitmessage.com, auth via the x-api-key header.
Kudosity is now available in two new places on GitHub: as a Copilot extension for natural-language messaging from VS Code, and as a GitHub Action for sending an SMS from any CI workflow.
GitHub Copilot Extension
Send SMS, MMS, manage contact lists, and configure webhooks from GitHub Copilot in VS Code using natural language. The extension uses the Kudosity MCP server for API documentation and your own credentials to execute requests locally — no message data or credentials leave your machine. Requires Copilot Agent Mode.
Send SMS and MMS from Copilot Chat (Agent Mode)
Create and manage contact lists for campaign sends
Configure delivery, inbound, and link-tracking webhooks
Authenticates via shell environment variables — no keychain or cloud storage
Drop into any GitHub Actions workflow to send an SMS as a single step. Now published on the GitHub Marketplace. Best for deploy notifications, on-call alerts when builds fail, and scheduled reminders.
Single-purpose send-SMS via the Kudosity V2 API
Composite YAML action — no Docker image, no JavaScript runtime
Repository-secret-based authentication with ::add-mask:: log scrubbing
Step outputs (message-id, status) for downstream verification
Pin to the moving @v1 tag for patch updates, or to a specific tag or SHA for reproducibility
We’ve rolled out a major improvement to our developer portal’s MCP server — introducing Smart API Version Routing.
When users or AIs ask general questions like “How do I send an SMS?” or “How do I send an SMS and get delivery reports?”, the system now asks a few short clarifying questions before recommending V1 or V2.
This ensures the assistant consistently provides the correct authentication method and endpoint, removing confusion between similar V1 and V2 functionality.
📊 New API Endpoints for RCS and WhatsApp
Message Retrieval and Statistics APIs
We've introduced comprehensive endpoints for programmatic access to RCS and WhatsApp message data. These APIs allow developers to retrieve individual messages and generate aggregated statistics for reporting and analytics.
RCS APIs
Retrieve Individual RCS Messages
Endpoint: GET /v2/rcs/{id}
Retrieve detailed information about specific RCS messages — including delivery status, timestamps, content, and pricing
RCS Aggregated Statistics
Endpoint: GET /v2/rcs/stats
Query parameters: start_at, end_at (ISO 8601), optional sender filter
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:
Contact Support: Reach out to register your RCS Agent ID
API Integration: Use the new /v2/rcs endpoint
Webhook Setup: Configure webhooks to track RCS_STATUS events
Test Messages: Start with Basic RCS messages, then explore Simple RCS features
📋 Message Types Comparison
Feature
Basic RCS
Simple RCS
SMS Fallback
Character Limit
160 characters
3,072 characters
160 characters
UTF-8 Support
✅
✅
✅
Emoji Support
✅
✅
✅
Read Receipts
✅
✅
❌
Rich Formatting
Limited
✅
❌
💬 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.
We are slightly modifying the datetime format used in the webhook API.
Old Format
New Format
2025-05-14T01:05:15.728779000Z
2025-05-14T01:05:15.728779Z
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:
