Legacy Dev Forum Posts

 View Only

Sign Up

/api/v2/telephony/providers/edges/trunks?trunkType=edge not filtering trunks

  • 1.  /api/v2/telephony/providers/edges/trunks?trunkType=edge not filtering trunks

    Posted 06-05-2025 18:02

    draeder | 2021-03-24 15:48:37 UTC | #1

    I've been trying to filter on only the trunkType=edge using the trunks endpoint, but all trunks are being returned despite the filter.

    This is my code, which is very minimal, so it makes me question if something beyond my code is causing this issue...

    const fetch = require('node-fetch')

    let params = { method: 'GET', headers: {'Authorization': tokenType + " " + accessToken} } let trunksUrl = "https://api.mypurecloud.com/api/v2/telephony/providers/edges/trunks?trunkType=edge"

    fetch(trunksUrl, params) .then(res => res.json()) .then(json => { console.log(json) })

    This returns the following, which is the same result as without the trunkType filter:

    pageSize: 25, pageNumber: 1, total: 122, firstUri: '/api/v2/telephony/providers/edges/trunks?pageSize=25&pageNumber=1', selfUri: '/api/v2/telephony/providers/edges/trunks?pageSize=25&pageNumber=1', nextUri: '/api/v2/telephony/providers/edges/trunks?pageSize=25&pageNumber=2', lastUri: '/api/v2/telephony/providers/edges/trunks?pageSize=25&pageNumber=5', pageCount: 5

    However, the API explorer, using the same URL and filter returns:

    "pageSize": 25, "pageNumber": 1, "total": 40, "firstUri": "/api/v2/telephony/providers/edges/trunks?pageSize=25&pageNumber=1&trunkType=edge", "selfUri": "/api/v2/telephony/providers/edges/trunks?pageSize=25&pageNumber=1&trunkType=edge", "lastUri": "/api/v2/telephony/providers/edges/trunks?pageSize=25&pageNumber=2&trunkType=edge", "nextUri": "/api/v2/telephony/providers/edges/trunks?pageSize=25&pageNumber=2&trunkType=edge", "pageCount": 2


    John_Carnell | 2021-03-24 17:24:14 UTC | #2

    Hi Dan,

    I was not able to reproduce the problem on my end using the public API and the API explorer. In both cases, the code was returning a consistently filtered list. On your API call could you post the ININ-Correlation-Id passed back in the response header from both your API explorer call and your Javascript call. We can use those correlation ids to look at the logs and see if we see anything unusual.

    Thanks, John Carnell Manager, Developer Engagement


    draeder | 2021-03-24 18:27:43 UTC | #3

    Here is the correlation id for the API explorer call: 813f9717-34e2-4241-9b69-890bd2c6ec4f Here is the same for my code's API call: a3a4eee5-fd1c-4136-8d93-8a3843b12978

    Thanks, Dan


    draeder | 2021-03-30 17:53:49 UTC | #4

    Hi John,

    I'm just checking in to see if your team has been able to review the correlation ID's I provided.

    Thanks, Dan


    John_Carnell | 2021-03-30 18:01:42 UTC | #5

    Hi Dan,

    Weird for whatever reason I did not get the notification for this. I will get this over to our development teams and see if I can get you more information. Sorry for the delay on this. I am going to have to investigate why I did not get notified.

    Thanks, John


    draeder | 2021-03-30 18:06:13 UTC | #6

    Hi John, No worries - if it helps the investigation for why you didn't get a notification, I never moved away from the page / refreshed it when I sent the response, so that might have something to do with it. Also, I'm using Safari.

    Thanks, Dan


    John_Carnell | 2021-03-30 20:35:11 UTC | #7

    Hi Dan,

    So I took a look at the difference between the API Explorer request vs. your API request.

    On the API Explorer request, I can see a trunkType=EDGE being passed as a query parameter in the HTTP call. In your example API call, you are passing trunkType=edge.

    I looked through our platform API and the API restricts to the values EXTERNAL, PHONE, EDGE so my guess is that the API is case-sensitive and you need to change your query parameter to uppercase and it should work. Please let me know if that does not work.

    Thanks, John Carnell Manager, Developer Engagement


    draeder | 2021-03-30 20:49:03 UTC | #8

    Hi John,

    I did consider that and tried both upper and lower cases. I don't have the correlation ID for the upper case request from my code. However, I tried both upper and lower case with the API Explorer as well and the API Explorer properly filtered the request in both scenarios. Is there anything else that stands out in the logs?

    I can duplicate again with upper case and get the correlation ID for that too if you would like.

    Thanks, Dan


    John_Carnell | 2021-03-30 20:50:24 UTC | #9

    Hi Dan,

    Could you please post those? That would help tremendously.

    Thanks, John Carnell Developer Engagement


    draeder | 2021-03-30 21:08:53 UTC | #10

    Hi John,

    I'm now getting a server 500 error for any request I send to that endpoint:

    Correlation ID: 3e3b5562-778f-48ef-bef2-35d47997f0f0 { message: 'The server encountered an unexpected condition which prevented it from fulfilling the request.', code: 'internal.server.error', status: 500, contextId: '3e3b5562-778f-48ef-bef2-35d47997f0f0', details: [], errors: [] }

    My code really hasn't changed:

    params = { method: 'GET', headers: {'Authorization': data.authType + " " + data.token} }

    let trunksUrl = "https://api.mypurecloud.com/api/v2/telephony/providers/edges/trunks/metrics?trunkType=EDGE"

    fetch(trunksUrl, params) .then(res => { console.log("Correlation ID: ", res.headers.get('inin-correlation-id')) return res.json() }) .then(json => { console.log(json) })

    Here is the correlation ID from API Explorer for the same request: 6d5f2e85-170f-4e67-a34c-5a968cadcd1d

    Notably, I can get the list of edges without any issues on the same runtime using "/api/v2/telephony/providers/edges" with the same access token.

    Thanks, Dan


    John_Carnell | 2021-03-30 21:36:19 UTC | #11

    Hi Dan,

    For the 500 error, I would open a ticket with our CARE. It appears you are hitting a different endpoint (API/v2/telephony/providers/edges/trunks/metrics) then what you are reporting above.

    I did a brief scan of the logs and I am seeing some of our circuit breakers popping on that call so the individual service owner will need to get a CARE ticket and then investigate. Make sure you include the contextId in your ticket because it will help them track down the issue.

    Thanks, John Carnell Manager, Developer Engagement


    draeder | 2021-03-30 21:44:50 UTC | #12

    Hi John,

    Ooops! Thank you, good catch. I somehow confused the endpoint URL on the latest test.

    Now for some reason I am getting the trunks filtered as expected. It very well could have been something on my side the whole time. And if so, my apologies.. Thank you for all of the help!

    (As for the server 500 error, it could be because this is part of the notifications API -- I'll address with CARE if the issue pops up again when I build out that piece )

    Thanks, Dan


    John_Carnell | 2021-03-31 12:39:07 UTC | #13

    Hey Dan,

    No worries. I am just glad it's working. Don't be afraid to post if you see weird inconsistencies again.

    Thanks, John Carnell Manager, Developer Engagement


    system | 2021-05-01 12:53:28 UTC | #14

    This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.


    This post was migrated from the old Developer Forum.

    ref: 10394