Pushing SMS inbound data to the mypurecloud.com.au messaging endpoints and the webhook keeps rejecting the +61 number format with a 400 Bad Request.
It’s sitting at v2024.5.2 and the latency from the Sydney edge is doing jack all for the ACMA compliance logger. Swapped the payload to a stripped E.164 format for now, but the routing rules can’t parse the local mobile prefixes.
Logs show the digest mismatch right at the validation step.
The 400 error usually hits when the webhook_signature_secret doesn’t match the decoded payload hash. It’s a direct validation failure. The validation logic works exactly like a SAML assertion check. The Sydney edge expects the full E.164 string inside the phone_number field before it calculates the HMAC digest. If you strip the country code early, the validation step fails because the signed body changes. Try passing the raw +61 format directly to the endpoint and handle the prefix parsing downstream. Here is the exact header mapping that fixes the digest mismatch:
{
"x-genesys-signature": "sha256={{signature}}",
"content-type": "application/json",
"phone_number": "+614XXXXXXXX"
}
Check the older community post on webhook payload signing for the base64 encoding steps. What IdP config sits between your messaging stack and Genesys? Pretty common hiccup. Certificate rotation usually causes this drift.