Queue API Implementation Issues

VitalPBX
1

Hello,

I’ve been working with the queue API for agent login/logout functionality and status checking. During my implementation, I’ve noticed several inconsistencies and potential issues with the API responses.

What we see

When calling the queue api to login agents to queues, we see that we can do as follows.

curl --location 'http://localhost/api/v2/devices/12/queues-login' \
--header 'app-key: API_KEY' \
--header 'tenant: 1' \
--form 'queues="all"'

Which returns

{
    "status": "success",
    "message": null,
    "data": {
        "1": true,
        "2": true,
        "3": true,
        "9": true,
        "19": true
    }
}

When we call the logout endpoint, we get the following response:

{
    "status": "success",
    "message": null,
    "data": {
        "1": {
            "status": false,
            "paused": false,
            "queue": "Q800",
            "type": "unknown"
        },
        "2": {
            "status": false,
            "paused": false,
            "queue": "Q801",
            "type": "unknown"
        },
        "3": {
            "status": false,
            "paused": false,
            "queue": "Q803",
            "type": "unknown"
        },
        "9": {
            "status": false,
            "paused": false,
            "queue": "Q808",
            "type": "unknown"
        },
        "19": {
            "status": false,
            "paused": false,
            "queue": "Q99001",
            "type": "unknown"
        }
    }
}

Further to that, if we pass a list of queue IDs, it does not actually work:

curl --location 'http://localhost/api/v2/devices/12/queues-login' \
--header 'app-key: API_KEY' \
--header 'tenant: 1' \
--form 'queues="1,2"'

We get the following response:

{
    "status": "success",
    "message": null,
    "data": []
}

Finally, when we call the http://localhost/api/v2/devices/12/queues/status endpoint we get the following:

{
    "status": "success",
    "message": null,
    "data": {
        "1": {
            "status": false,
            "paused": false,
            "queue": "Q800",
            "type": "unknown",
            "description": "Support"
        },
        "2": {
            "status": false,
            "paused": false,
            "queue": "Q801",
            "type": "unknown",
            "description": "Operator"
        },
        "3": {
            "status": false,
            "paused": false,
            "queue": "Q803",
            "type": "unknown",
            "description": "Limited"
        },
        "9": {
            "status": false,
            "paused": false,
            "queue": "Q808",
            "type": "unknown",
            "description": "Escalations"
        },
        "19": {
            "status": false,
            "paused": false,
            "queue": "Q99001",
            "type": "unknown",
            "description": "Testq1"
        },
        "4": {
            "status": true,
            "paused": false,
            "queue": "Q805",
            "type": "static",
            "description": "Cellphone Queue"
        },
        "5": {
            "status": true,
            "paused": false,
            "queue": "Q806",
            "type": "static",
            "description": "Evening Queue"
        }
    }
}

Issues

The data is very inconsistent across different API calls. Here are the specific issues I’ve identified:

1. Inconsistent Response Formats

The login and logout responses have different structures, making it difficult to process the data consistently. Ideally, the logout response should match the login response format, indicating success or failure for each queue individually.

2. Multiple Queue IDs Not Functioning

The API appears to have stopped accepting multiple queue IDs (e.g., queues=1,2,19). This functionality seems to be broken unless I’m missing something in the implementation.

3. Misleading Success Status

When passing an incorrect queue ID, the API still returns a "status": "success". This is misleading and should instead return an error message for invalid inputs.

4. Empty Message Field

The message field is consistently null across all responses. This field could be utilized to provide additional context or information about the API call results.

5. Incorrect Type Classification

For dynamic members, the type field incorrectly shows "type": "unknown" instead of the expected "type": "dynamic". This misclassification can lead to confusion and potential errors in client applications.

6. Ambiguous Status Field

In the /api/v2/devices/12/queues/status endpoint response, the status field (e.g., "status": false, or "status": true,) can be ambiguous. A more descriptive field name like "loggedin": true, or false would provide clearer information about the agent’s current state in the queue.

Conclusion

These inconsistencies and issues in the queue API responses make it challenging to implement reliable client-side logic. Any insights or workarounds would be greatly appreciated.

2 Likes