Genesys Cloud - Developer Community!

Hi guys ,

Would like to ask for guidance regarding a VOICE agentless outbound campaign callback use case and the deprecation of the endpoint:
POST /api/v2/outbound/campaigns/{campaignId}/callback/schedule.

We have a VOICE agentless campaign, and inside the IVR flow there is a path where the customer can request a callback in order to be contacted again by the campaign at a future time/date.

The current deprecated endpoint fits this use case because it allows scheduling callbacks directly against the outbound campaign context.

However, the proposed alternative endpoints:

• /api/v2/conversations/{conversationId}/participants/{participantId}/callbacks
• /api/v2/conversations/callbacks

do not cover our use case properly.

The main blocker is that the proposed callback APIs require queue-based routing logic and mandatory queueId/name usage.

In our architecture, this information does not exist because:

• the campaigns are fully agentless,
• there is no ACD queue involved,
• and agentless campaigns do not provide/require queueId association.

Because of this, the proposed migration path does not appear compatible with VOICE agentless outbound campaign callback scheduling.

Any guidance, architectural recommendation, or alternative approach for handling this use case would be highly appreciated.

Thank you in advance for your time and help.

Markos

Hi Markos,

We evaluated a very similar scenario recently for agentless outbound reminder/retry campaigns, and from what we could validate in the current Genesys Cloud documentation/API behavior, your concern is valid.

The deprecated endpoint:

POST /api/v2/outbound/campaigns/{campaignId}/callback/schedule

was one of the few APIs that operated directly in the outbound campaign context itself without requiring ACD queue semantics.

The newer callback APIs are much more conversation/ACD-oriented and appear designed primarily for agent-based callback routing models, which creates a gap for pure agentless outbound architectures.

From what we observed, the replacement APIs:

/api/v2/conversations/{conversationId}/participants/{participantId}/callbacks
/api/v2/conversations/callbacks

assume callback ownership through queues and routing infrastructure, including queueId association and callback conversation lifecycle management.

That becomes problematic for:

• fully agentless outbound campaigns
• IVR-only retry flows
• campaign-driven recontact logic
• proactive notification campaigns
• no-agent/no-queue architectures

In practice, the approaches we have seen customers evaluate are usually one of these:

1. External callback orchestration layer

Instead of scheduling directly through the outbound campaign callback API, the IVR stores the callback request externally (CRM/database/middleware), and an external scheduler later re-injects the contact into the campaign using APIs such as:

• Contact List APIs
• Campaign Contact APIs
• Dynamic contact recycling
• Scheduled data imports

This is currently the cleanest long-term architecture we have found for agentless retry/recontact use cases.

2. Separate queue-backed callback handling

Technically possible, but usually architecturally awkward for agentless environments because it introduces:

• artificial queues
• callback conversations
• routing complexity
• agent-centric semantics

for a workflow that is not actually agent-based.

3. Hybrid orchestration

Some customers maintain the campaign for the outbound dialing itself but move callback scheduling/orchestration into middleware logic completely.

For example:

IVR callback request
→ external persistence
→ scheduler/service bus
→ campaign contact reinjection
→ outbound dialing resumes later

Operationally, this tends to scale better and gives much stronger control over:

• retry policies
• timezone handling
• deduplication
• throttling
• compliance windows
• idempotency
• reporting enrichment

One important consideration:
because the original endpoint is deprecated, I would be cautious about building new production dependency around campaign-native callback scheduling even if it still currently functions.

At the moment, I have not found documentation indicating a direct 1:1 replacement API specifically for agentless outbound campaign callback scheduling without queue association.

So based on the current API model, your interpretation appears correct:
the proposed migration path does not fully cover pure VOICE agentless outbound callback scenarios today.