Webhook #1 that will fail supervise with a 409 code. 
 

 {
  "uuid": "2191365001387699707",
  "event": "/restapi/v1.0/account/1794412020/extension/1424277024/telephony/sessions",
  "timestamp": "2025-05-16T20:51:30.816Z",
  "subscriptionId": "4d1be646-cc30-42f2-9ef4-fc989451c631",
  "ownerId": "1115545024",
  "body": {
    "sequence": 4,
    "sessionId": "548835777025",
    "telephonySessionId": "s-a0e177719a6cbz196daddca2dz9c17960000",
    "serverId": "10.14.23.119.TAM",
    "eventTime": "2025-05-16T20:51:30.609Z",
    "parties": :
      {
        "accountId": "1794412020",
        "extensionId": "1424277024",
        "id": "p-a0e177719a6cbz196daddca2dz9c17960000-1",
        "direction": "Outbound",
        "to": {
          "phoneNumber": "+14167259964"
        },
        "from": {
          "phoneNumber": "+14169624047",
          "extensionId": "1424277024",
          "deviceId": "803570947025"
        },
        "status": {
          "code": "Answered",
          "rcc": false
        },
        "park": {},
        "missedCall": false,
        "standAlone": false,
        "muted": false
      }
    ],
    "origin": {
      "type": "Call"
    }
  }
}

And webhook #2 that will succeed the supervise request:
 

 {
  "uuid": "6919148098334221507",
  "event": "/restapi/v1.0/account/1794412020/extension/1424277024/telephony/sessions",
  "timestamp": "2025-05-16T20:51:39.354Z",
  "subscriptionId": "4d1be646-cc30-42f2-9ef4-fc989451c631",
  "ownerId": "1115545024",
  "body": {
    "sequence": 6,
    "sessionId": "548835777025",
    "telephonySessionId": "s-a0e177719a6cbz196daddca2dz9c17960000",
    "serverId": "10.14.23.119.TAM",
    "eventTime": "2025-05-16T20:51:38.872Z",
    "parties": "
      {
        "accountId": "1794412020",
        "extensionId": "1424277024",
        "id": "p-a0e177719a6cbz196daddca2dz9c17960000-1",
        "direction": "Outbound",
        "to": {
          "phoneNumber": "+14167259964"
        },
        "from": {
          "phoneNumber": "+14169624047",
          "extensionId": "1424277024",
          "deviceId": "803570947025"
        },
        "recordings": "
          {
            "id": "2013560064025",
            "active": true
          }
        ],
        "status": {
          "code": "Answered",
          "rcc": false
        },
        "park": {},
        "missedCall": false,
        "standAlone": false,
        "muted": false
      }
    ],
    "origin": {
      "type": "Call"
    }
  }
}

They are identical except that second one have “recordings” prop. but i don’t think it is related at all to my issue.

In your case, the call seems to be automatic recording and every time a call is started recording, paused or resumed, the system always fires an event for that session with the call status is “Answered”.

So, you need to check the recordings object existence and ignore those events.

There are some other cases when the system fires event with the status = “Answered” too. Please read this article to learn more.

​@PhongVu Hmm, alright but what if there is no automatic recording is enabled, in that case i will fail to supervise? Because i only can supervise after the recording have started.

Is there any other way to determina when does the phone been actually answered?

I did not mean that only when a call is automatically recorded. It’s when a call is recorded either automatically or manually. But if and when that happens, it always happens after the call is answered (connected). So you just get the first event with status is “Answered” (provided that the events come in the right other. Check the sequence number.) then you can start supervise the call. You can then ignore other event with the status=Answered because they are the events for recording or resumed from on-hold etc.

Thats exactly my point - the first “Answered” event is resulting in 409 Conflict. The sequence of the first event is 4 compared to the second “Answered” with sequance 6. The supervise request only succeeds on the second “Answered” event.

What are you describing is not working.

Oh, now I pay attention to the direction of the call you tested. It’s an Outbound call.

For outbound call, the “Answered” status of the first leg (partyId-1) is not the event when the call is answered by the callee. It’s the status when the SIP server sends 200 OK to the caller phone. This is a “known issue” but by design to support the greeting feature.

In your case, you must subscribe for the telephony sessions event at the account level ('/restapi/v1.0/account/~/telephony/sessions') so you will receive the events when the remote (callee) party answers the call.

For an outbound call, check the status of the event with the partyId ends with “-2”. And for an inbound call, check the status of the event with the partyId ends with “-1”. They are event fired for the other call party who answers the call.

Well but subscribing to account level is not what we need, i need to subscribe only to a few extensions rather than to the whole account….

It is very confusing. Howcome the “answered” event is not “answered”…. and i still do not understand why do i have 409 conflict on initial answered event but sucess on the one that is following.

I have went ahead and improved myu supervise logic.

Before supervision now i am getting the sessionn info from:

`/restapi/v1.0/account/~/telephony/sessions/${sessionId}`

I then check if all parties have answered status and only if they do i try to supervise, still the same error happens.

const endpoint = `/restapi/v1.0/account/~/telephony/sessions/${sessionId}`;
const res = await platform.get(endpoint);
const json = await res.json();
if (!json.parties.map(p => p.status.code).every(status => status === "Answered")) {
    console.log('All parties not answered yet')
    return
}

.. SUPERVISE REQUEST HERE

It does not make sense at all….