Fun one today. We’re seeing intermittent 400 Bad Requests on Data Actions triggered from wrap-up codes - specifically the screen pop action. It started immediately after the latest Salesforce Winter '24 refresh. The flow hasn’t changed, the Data Action payload hasn’t changed - nothing on our end should be causing this.
Here’s what we’ve got. The Data Action itself is pretty simple - it’s just a POST to /api/v2/externalcontacts/contacts/enrich using the contact’s phone number as the search key. We’re using the Zoom Contact Center Python SDK - version 2.0.1. The relevant part of the Architect flow is a wrap-up code set to “Case Created,” which then fires the Data Action.
The errors are happening maybe one in ten times. The Zoom Contact Center logs show a 400 Bad Request and a message about “Invalid input.” We’ve checked the contact data being sent - phone number is valid, no weird characters. Salesforce side, the API user has all the correct permissions.
We’ve tried a few things - increased the timeout on the Data Action (didn’t help), and doubled-checked the field mapping in the Data Action configuration. Nothing’s worked. We suspect the Salesforce Winter '24 update has introduced some change to the API that the SDK isn’t handling correctly.
The API request in the logs looks like this:
POST /api/v2/externalcontacts/contacts/enrich
Content-Type: application/json
{
"phoneNumber": "+15551234567"
}
Check the request body - Salesforce changed how they handle phone numbers in the search endpoint. You’ll need to encode the phoneNumber as a JSON array - ["1XXXXXXXXXX"]. Saw this pop up last week in a similar thread.
Also - make sure the user making the API call has the right Salesforce permissions. Searching for external contacts requires api access.
That worked - wrapping the phone number in an array fixed it instantly. We’re on Zoom Contact Center, Genesys Cloud and hadn’t seen that documented anywhere, so thanks for pointing that out. It was a silent change on the Salesforce side, which is always…fun.
That Salesforce change is… unexpected. The documentation doesn’t mention array formatting for the phone number - it still shows a string. Though, to be fair, the documentation hasn’t been updated since last June.
What’s concerning is the inconsistency - it’s not a documented breaking change, so it’s likely they’re throttling requests if the format is wrong. We’ve seen this pattern before with their API. Not 100% sure but the 400 could be a polite way of saying “slow down.”
For what it’s worth - if you’re hitting this frequently, you might want to consider caching the Salesforce contact ID locally. Repeated lookups on every wrap-up will hit limits faster. Something like this for a payload:
The ‘cacheKey’ is just an example - you’ll need to map that to your own system. And, yeah, permissions are critical too. The API user needs full access.
It sounds like you’ve hit a fairly common snag with Salesforce Data Actions - the API documentation often lags behind actual platform behavior.
Here are a few things to consider, building on the earlier reply about the phone number array - and I’ve seen this referenced in a few posts over the last couple of months.
Field Mapping: Double-check your field mappings in the Data Action - even seemingly minor discrepancies between the Genesys Cloud data and Salesforce field types can cause 400 errors.
Rate Limiting: As mentioned previously, Salesforce imposes rate limits. If you’re processing a high volume of wrap-ups, you might be hitting those limits, and the 400 could be a symptom of throttling rather than a formatting issue.