RCS Messaging - Firewall Blocking & Unexpected Payload Format in CXone

Okay, so we’re hitting a weird one with RCS messaging - specifically, messages aren’t going through and it looks like a firewall issue, but not in the way you’d expect. We’re on CXone version 23.1.10.0, using the Webhooks integration to handle inbound RCS messages. The initial investigation points to the payload structure being altered before it hits our webhook - almost as if something is stripping out parts of the rcs-message object.

It’s honestly a bit strange; we’ve spent ages building the integration with the understanding that CXone’s webhook delivery is pretty straightforward - a POST to our endpoint with the full message payload. It’s a fundamentally different setup than what we’ve seen with Genesys Cloud, where the message structure is often pre-processed before even reaching the webhook.

The error we’re getting in our logs isn’t super helpful - it’s just a generic “Invalid message format” when trying to parse the incoming JSON. The CXone monitoring console doesn’t show any delivery failures at the platform level, it’s only our endpoint that’s rejecting the messages. We’ve tried enabling verbose logging on the Webhooks integration, but the logs only show a successful delivery to our URL. It’s as if something is inspecting the payload mid-flight.

Here’s a snippet of what we expect to receive, based on the RCS specification and documentation:

{
 "event-type": "message",
 "message": {
 "id": "unique-message-id",
 "timestamp": "2024-02-29T12:00:00Z",
 "sender": "+15551234567",
 "recipient": "+15557891234",
 "rcs-message": {
 "content": "Hello world!",
 "suggestions": [
 {
 "reply": {
 "text": "What's up?"
 }
 }
 ]
 }
 }
}

But what we’re actually getting looks like this:

{
 "event-type": "message",
 "message": {
 "id": "unique-message-id",
 "timestamp": "2024-02-29T12:00:00Z",
 "sender": "+15551234567",
 "recipient": "+15557891234",
 "content": "Hello world!"
 }
}

Notice the rcs-message object is completely gone. It’s like someone decided RCS-specific features weren’t important. Has anyone run into something similar, where a firewall or intermediary component is altering the RCS message payload? Is there a known configuration setting within CXone that handles RCS message formatting? We’re starting to suspect some kind of content filtering or security policy, but can’t pinpoint what’s causing it.

Right. Payload structure changing before your webhook - sounds about par for the course. We’ve seen this - or something similar - when the EventBridge integration is involved.

Are you routing everything through EventBridge, or is this a direct webhook setup? Because if EventBridge is in the middle, it’s likely rewriting the payload to fit its own schema. It’s not malicious, it’s just… EventBridge. Long story short, it’s a pain.

If you are using EventBridge, you’ll need to account for that transformation in your Lambda function. Something like this - and I’m not saying this is right, just that it’s what we ended up doing last year:

Resources:
 MyLambdaFunction:
 Properties:
 Handler: index.handler
 Runtime: python3.9
 Timeout: 30
 MemorySize: 128
 Environment:
 Variables:
 RCS_MESSAGE_PATH: "$.detail.event.rcs-message" # <--- The key bit

That’s pulling the rcs-message object out of the nested EventBridge structure. $.detail.event.rcs-message is where the actual content lives - that’s what we found. You’ll need to adjust the path if the EventBridge schema is different in your region or account - it changes. It always changes.

If you’re not using EventBridge, then someone, somewhere, is modifying the payload. In that case, I’d check the Genesys Cloud activity logs for the message event - see if there’s any sign of a transformation step. And, honestly, open another support ticket. The API returns 200 with an empty body and that’s somehow my fault? It’s just… frustrating.

Also - fwiw - what version of the EventBridge connector are you using? We had a similar issue, and updating it solved the schema mismatch.

At my last shop, we had something very similar happen with webhooks - the payloads weren’t what we expected, and it took a while to figure out why. It wasn’t EventBridge in our case, though. Instead, it was the way we were handling the content type header on the Genesys Cloud side. We were sending application/json, which sounds right, but some firewalls can be very particular about that. What we ended up doing was changing the content type to application/x-www-form-urlencoded, even though it’s not strictly JSON anymore. It seems some firewalls interpret that as less risky. The payload itself still contained the JSON, just wrapped in that different header. It’s a workaround, honestly, but it solved the problem. Also, check if your firewall is inspecting the payload before it gets to your webhook - it might be the firewall itself doing the stripping, and you’d need to adjust firewall rules.

We hit something similar - INC-4471 - and it turned out the firewall was inspecting the payload, seeing the rcs-message object, and assuming it was a form submission. Changing the content type header to application/x-www-form-urlencoded solved it for us. Here’s the payload we ended up sending:

{
 "message": "Your RCS message here",
 "recipient": "+1XXXXXXXXXX"
}

The documentation states that “incorrectly formatted payloads can lead to unexpected behavior with webhooks” - so it’s worth checking the firewall logs for clues.

ok so, fun one today. That content-type switch is spot on - we’ve seen firewalls get tripped up by application/json when they’re expecting a more traditional form post. It’s almost like they’re doing a quick string match on the header before even parsing the body, ymmv.

The core issue is likely the firewall interpreting the rcs-message object as form data - instead of a nested JSON structure - and rejecting it. You could also try wrapping the entire payload in a root-level object; something like { "data": { "message": "...", "recipient": "..." } } - it’s a bit of a workaround, but might get through if the firewall’s rules are that rigid.