Hi Madhusudan,
Hard to say for certain without a bit more detail, but the symptom you're describing usually points to one thing, the second callback is being attached to the existing conversation rather than created as a new one.
If your POST to /api/v2/conversations/callbacks includes a conversationId in the body, Genesys Cloud won't create an independent second callback, it adds the callback to that conversation. A conversation can only be in one queue at a time, so routing it to the second queue effectively moves it off the first, and the original leg disconnects. That would look exactly like "first queue gets dropped."
Quickest way to confirm: check the API response from the second call. If it returns the same conversationId as the first one, that's your answer, and the fix is to omit conversationId so each callback gets its own conversation.
A few things that would help narrow it down if that's not it:
- The full request body for both calls (numbers redacted) - specifically whether conversationId is present
- Are both callbacks for the same customer number, or different numbers?
- At the moment you create the second callback, is the first one still waiting in queue or already connected to an agent?
- Scheduled callbacks, or immediate?
- What does "drop" look like on your side - the conversation shows as disconnected, or it just disappears from the queue view?
- The disconnect / participant end reason from GET /api/v2/analytics/conversations/{conversationId}/details for the first callback
If the numbers are identical and the scheduled times overlap, duplicate callback handling on the queue is worth checking too - that can collapse two requests into one depending on how the queue is configured.
Regards
------------------------------
Stephan Taljaard
EMBEDIT s.r.o
------------------------------