Issue with "List service connections"

Documentation link

https://pan.dev/access/api/prisma-access-config/get-sse-config-v-1-service-connections/

Describe the problem

Your documentation states that when you create a secondary tunnel you have the option of setting option "same_as primary" value true or false, but you donot see that in the return and when that's flagged that never comes back. Yet instead the organiztion of the returned response is massively confusing. You have to understand that the secondary BGP peer is the same if there are two peers inside the "protocol, bgp" nest... than you have to correlate the secondary BGP configurations under another json object called bgp_peer.

The response itself shows how confusing this is and disconnect from the docs are with the calls which is problematic when trying to create these objects:

{
  "data": [
    {
      "id": "6deff6da-bd3d-45a7-92d1-d5a60ab3e397",
      "name": "Test_service",
      "region": "us-west-1",
      "ipsec_tunnel": "ipsec-tunnel-test-sc-01",
      "onboarding_type": "classic",
      "subnets": [
        "192.168.1.193/32"
      ],
      "protocol": {
        "bgp": {
          "enable": true,
          "peer_ip_address": "192.168.1.193",
          "peer_as": "65533",
          "local_ip_address": "192.168.0.5"
        },
        "bgp_peer": {
          "peer_ip_address": "192.168.100.100",
          "local_ip_address": "192.168.0.5"
        }
      },
      "secondary_ipsec_tunnel": "ipsec-tunnel-sc-02",
      "bgp_peer": {
        "peer_ip_address": "192.168.100.100",
        "local_ip_address": "192.168.0.5"
      }
    }
  ],
  "offset": 0,
  "total": 1,
  "limit": 200
}

Suggested fix

use secondary destinations or separate the nested structure in a manor that is understandable not having to make assumptions as to where you are putting what information as this now leads to a really confusing way to build the data structure that doesn't look like examples so i can't tell what's valid and what's not. Which has lead me to bugs with your API in the past causing issues due to confusions with the documentation as well as unorganized structured returned objects leading to confusion on whats needed when i need to create said data structure

Start with the linked List service connections documentation page and compare its stated secondary-tunnel fields with the example response in this issue. Done means the valid request and response structure, including the secondary BGP information and same_as_primary behavior, are unambiguous.