Hey! Stackoverflow style help needed here. I’m the Edge appliance admin and I’m trying to build a ‘Self-Healing’ IVR. I want my Architect flow to check the health of our local on-prem Edges before it attempts to route a call. I’m using the GET /api/v2/telephony/providers/edges endpoint in a Data Action. When I run the query, I get a ‘200 OK’ but the entities array is completely empty, even though I have four Edges active in the Admin UI. Is there a hidden ‘Division’ filter on the Telephony API that I’m missing, or do on-prem Edges require a different endpoint than cloud Edges?
Good afternoon. I am a digital channels specialist and I’ve dealt with these types of visibility issues during our chat integrations. The edges endpoint is indeed division-aware. If your OAuth Client ID (the one used for the Data Action) is only granted access to the ‘Home’ division, it will not be able to see Edges that are assigned to a specific ‘Physical Site’ in a different division. Most enterprise on-prem Edges are assigned to a site for regional routing. You must explicitly grant your OAuth client ‘View’ permissions for the division where those sites reside. I have provided a detailed guide on division-aware API permissions below.
I’ve seen how these ‘Empty Array’ responses can break our AI modeling! In addition to the division permissions, ensure that your Data Action ‘Request Template’ isn’t including a default managed: true filter. Some on-prem Edges are considered ‘Unmanaged’ if they are running specific legacy firmware versions. If the API is only looking for ‘Managed’ Edges, it will skip your local appliances. Try removing all query parameters and see if the full list appears. It’s a common oversight during the migration of historical ETL scripts!
Good afternoon. I manage our data migration ETLs and I can confirm that the ‘Physical Site’ is the key. In the Genesys Cloud architecture, an Edge is ‘owned’ by a Site, and a Site is ‘owned’ by a Division. To see the health status, your Data Action needs the telephony:config:view permission globally across all divisions. We found that assigning the ‘Telephony Admin’ role to the OAuth client, while limiting it to the specific production divisions, is the safest way to ensure your ‘Self-Healing’ IVR always has the data it needs. It’s a much more scalable architecture than trying to map individual site permissions!