{"code": "invalid_list", "message": "The specified list does not exist or is not accessible."}
Trying to migrate a Zendesk contact list to a Genesys Cloud Outbound Campaign via the v2/outbound/lists endpoint. The list imports fine, but the campaign fails to start. In Zendesk, we just tagged tickets; here, the mapping seems stricter. Using Genesys Cloud SDK v1.0.2. Is there a specific permission or data format requirement for the contact fields that differs from the Zendesk CSV export?
This is caused by a mismatch in the list scope or access permissions. Ensure the list is marked as active and accessible to the campaign’s associated user or application. Check that the list ID matches exactly and that no pending import jobs are blocking access. Verify the OAuth token has outbound:campaign:write permissions.
This is caused by a mismatch in the list scope or access permissions. Ensure the list is marked as active and accessible to the campaign’s associated user or application. Check that the list ID matches exactly and that no pending import jobs are blocking access. Verify the OAuth token has outbound:campaign:write permissions.
The documentation actually says list visibility requires explicit sharing.
Cause: The migrated list lacks access grants for the campaign’s service account.
Solution: Grant outbound:campaign:write permissions and verify the list status is ACTIVE via the API. Ensure no import jobs are pending, as this blocks access. Check OAuth scopes for the application user.
This is caused by a discrepancy in how the list scope is defined during the import phase versus how the outbound campaign engine validates access rights. While the previous suggestions correctly identify the outbound:campaign:write scope requirement, the root issue often lies in the sharedTo property of the list object returned by the v2/outbound/lists endpoint. When migrating from Zendesk, the list is likely created with a private scope tied to the import user, making it invisible to the service account executing the campaign. The fix involves explicitly updating the list visibility via a PUT request to /api/v2/outbound/lists/{listId} with a payload that includes "sharedTo": ["everyone"] or the specific user group ID associated with your outbound application. Additionally, verify that the list status is strictly ACTIVE and not PENDING or PROCESSING, as any asynchronous import jobs will lock the list from campaign assignment. Cross-referencing the ServiceNow integration patterns, ensuring the list ID matches exactly without trailing whitespace is also critical for API resolution.