Hi all,
Quick question on how the clear endpoint actually handles active campaigns. We’ve been running some automation scripts to refresh our outbound lists every few hours to keep the data fresh.
Everything usually works fine, but we’ve hit a wall with one of our larger lists. When calling POST /api/v2/outbound/contactlists/{contactListId}/clear, it’s returning a 400 error. The weird part is that some contacts are actually getting wiped, but then it just stops halfway through.
The response body looks like this:
{
"message": "Unable to delete contacts that are currently in use by a campaign",
"code": "Bad Request",
"status": 400
}
We’ve tried pausing the campaigns first, but the error still pops up. It’s like some records are stuck in a “locked” state even though the campaign is inactive. Is there a specific delay we need to wait for after pausing before the clear call will actually work?
Side note, does this behave differently if the campaign is set to preview mode versus predictive? Not sure if that’s playing a role here.
1 Like
Are these lists tied to a campaign that’s currently running? If the records are locked, it’ll wreck the data refresh cycle and kill the adoption metrics I’ve promised the stakeholders.
1 Like
POST /api/v2/outbound/contactlists/{contactListId}/clear
The earlier reply is spot on. Active campaign locks trigger that 400. Stop the campaign first or the clear endpoint won’t touch locked records.
Ref: Outbound API v2
1 Like
await client.Outbound.clearContactList(contactListId);
PureCloudPlatformClientV2 makes this feel like a guessing game because the error messages are uselessly vague. The fix in the earlier reply is spot on. It’s just typical that we have to manually stop the campaign first because the API won’t just handle the lock release for us.
1 Like
Cause:
PureCloudPlatformClientV2 handles the request, but the backend logic for /api/v2/outbound/contactlists/{contactListId}/clear is designed to fail if any record is currently locked by the dialer. Theoretically, the system can’t perform a bulk wipe while the campaign engine has active pointers to those records for dialing or callback scheduling. This creates a race condition where even if the campaign is “stopped” in the UI, there might be a slight lag before the locks are released across the distributed edge. If the script hits the clear endpoint too fast, you’ll still get that 400.
Solution:
We ran into a similar headache during a high-volume refresh cycle. The trick is to implement a retry loop with a back-off timer to ensure the campaign state has fully propagated. Don’t just stop the campaign and immediately call the clear endpoint.
import time
from PureCloudPlatformClientV2.api import outbound_api
# Stop campaign first
outbound_api.patch_outbound_campaign(campaign_id, {"status": "inactive"})
# Wait for locks to release
max_retries = 3
for i in range(max_retries):
try:
outbound_api.post_outbound_contactlist_clear(contact_list_id)
break
except Exception as e:
if i == max_retries - 1: raise e
time.sleep(5) # Give the engine a moment to breathe
One gotcha: if you’ve got rule-scheduled callbacks, those get cancelled too, so that’s something to track in your reporting.
1 Like