IX-API

List (Query) **Operation:** `metro_area_networks_list` **Summary:** List all MetroAreaNetworks

Read **Operation:** `metro_area_networks_read` **Summary:** Retrieve a MetroAreaNetwork

List (Query) **Operation:** `metro_areas_list` **Summary:** List all MetroAreas

Read **Operation:** `metro_areas_read` **Summary:** Get a single MetroArea

Create **Operation:** `network_feature_configs_create` **Summary:** Create a configuration for a `NetworkFeature` defined in the `NetworkFeature`s collection.

Request Decommission **Operation:** `network_feature_configs_destroy` **Summary:** Remove a network feature config. The network feature config will be marked as `decommission_requested`. Decommissioning a network feature config will not cascade to related services or service configs.

List (Query) **Operation:** `network_feature_configs_list` **Summary:** Get all network feature configs.

Update **Operation:** `network_feature_configs_partial_update` **Summary:** Update a network feature configuration.

Read **Operation:** `network_feature_configs_read` **Summary:** Get a single network feature config.

Update (Deprecated) **Operation:** `network_feature_configs_update` **Summary:** **DEPRECATION NOTICE**: This operation will be removed in favor of using `PATCH` for all updates. Update a network feature configuration

List (Query) **Operation:** `network_features_list` **Summary:** List available network features.

Read **Operation:** `network_features_read` **Summary:** Get a single network feature by it's id.

Read Cancellation Policy **Operation:** `network_service_cancellation_policy_read` **Summary:** The cancellation-policy can be queried to answer the questions: If I cancel my service, *when will it be technically decommissioned*? If I cancel my service, *until what date will I be charged*? When the query parameter `decommision_at` is not provided it will provide the first possible cancellation date and charge period if cancelled at above date. The granularity of the date field is a day, the start and end of which are to be interpreted by the IXP (some may use UTC, some may use their local time zone).

Create Change Request **Operation:** `network_service_change_request_create` **Summary:** Request a change to the network service. The B-side participant in a peer-to-peer network service (`p2p_vc`) can issue a change request, expressing a desired change in the capacity. The change is accepted when the A-side has configured the network service and config with the new bandwidth. This is done using the `network_service_update`, `network_service_partial_update`, `network_service_config_update` or `network_service_config_partial_update` operations by the A-side. These changes can sometimes require a change of the product offering. The product offering may only differ in bandwidth. The network service will change its state from `production` into `production_change_pending`. A change can by rejected (by the A-side) or retracted (by the B-side) using the `network_service_change_request_destroy` operation. Only one change request may be issued at a time. A change request by the A-side is not a valid request and will be rejected.

Delete Change Request **Operation:** `network_service_change_request_destroy` **Summary:** Retract or reject a change to the network service.

Read Change Request **Operation:** `network_service_change_request_read` **Summary:** Get the change request.

Read Cancellation Policy **Operation:** `network_service_config_cancellation_policy_read` **Summary:** The cancellation-policy can be queried to answer the questions: If I cancel my subscription, *when will it be technically decommissioned*? If I cancel my subscription, *until what date will I be charged*? When the query parameter `decommision_at` is not provided it will provide the first possible cancellation date and charge period if cancelled at above date. The granularity of the date field is a day, the start and end of which are to be interpreted by the IXP (some may use UTC, some may use their local time zone).

Create **Operation:** `network_service_configs_create` **Summary:** Create a `network-service-config`.

Request Decommission **Operation:** `network_service_configs_destroy` **Summary:** Request decommissioning the network service configuration. The network service config will assume the state `decommission_requested`. This will cascade to related resources like `network-feature-configs`.

List (Query) **Operation:** `network_service_configs_list` **Summary:** Get all `network-service-config`s.

Update **Operation:** `network_service_configs_partial_update` **Summary:** Update an exisiting `network-service-config`.

Read Peer Statistics **Operation:** `network_service_configs_peer_statistics_read` **Summary:** Read the aggregated peer to peer statistics in relation to the peer represented by the `NetworkServiceConfig`. This operation will return a list of aggregated statistics. A `start` and `end` query parameter can be used to retrieve the aggregated traffic for a given window. In this case the key of the returned statistics is `custom`. With a given `start` and `end` window, the resolution for the aggregated data is chosen by the implementation. You need to check the `accuracy` attribute of the aggregate, to see if the data can be used for the desired usecase. The `accuracy` is the ratio of *total samples* to *expected samples*. If no `start` or `end` parameter is given, a sliding window is assumed and key value pairs of resolutions and aggregated statistics are returned.

Read Peer Statistics Timeseries **Operation:** `network_service_configs_peer_statistics_timeseries_read` **Summary:** Read peer to peer aggregated timeseries. The resolution is defined by the aggregate. This operation will return a list of timeseries for each peer.

Read **Operation:** `network_service_configs_read` **Summary:** Get a `network-service-config`

Read Statistics **Operation:** `network_service_configs_statistics_read` **Summary:** Read the aggregated statistics of a `NetworkServiceConfig`. A `start` and `end` query parameter can be used to retrieve the aggregated traffic for a given window. In this case the key of the returned statistics is `custom`. With a given `start` and `end` window, the resolution for the aggregated data is chosen by the implementation. You need to check the `accuracy` attribute of the aggregate, to see if the data can be used for the desired usecase. The `accuracy` is the ratio of *total samples* to *expected samples*. If no `start` or `end` parameter is given, a sliding window is assumed and key value pairs of resolutions and aggregated statistics are returned.

Read Statistics Timeseries **Operation:** `network_service_configs_statistics_timeseries_read` **Summary:** Read a `NetworkServiceConfig`s aggregated timeseries. The resolution is defined by the aggregate.

Update (Deprecated) **Operation:** `network_service_configs_update` **Summary:** **DEPRECATION NOTICE**: This operation will be removed in favor of using `PATCH` for all updates. Update an exisiting `network-service-config`

Create **Operation:** `network_services_create` **Summary:** Create a new network service

Request Decommission **Operation:** `network_services_destroy` **Summary:** Request decomissioning of the network service. The network service will enter the state of `decommission_requested`. The request will cascade to related network service and feature configs. An *optional request body* can be provided to request a specific service termination date. If no date is given in the request body, it is assumed to be the earliest possible date. Possible values for `decommission_at` can be queried through the `network_service_cancellation_policy_read` operation. The response will contain the dates on which the changes will be effected.

List (Query) **Operation:** `network_services_list` **Summary:** List available `NetworkService`s.

Update **Operation:** `network_services_partial_update` **Summary:** Update a network service

Read **Operation:** `network_services_read` **Summary:** Get a specific `network-service` by id.

Read Statistics **Operation:** `network_services_statistics_read` **Summary:** Read a `NetworkService`s aggregated statistics. A `start` and `end` query parameter can be used to retrieve the aggregated traffic for a given window. In this case the key of the returned statistics is `custom`. With a given `start` and `end` window, the resolution for the aggregated data is chosen by the implementation. You need to check the `accuracy` attribute of the aggregate, to see if the data can be used for the desired usecase. The `accuracy` is the ratio of *total samples* to *expected samples*. If no `start` or `end` parameter is given, a sliding window is assumed and key value pairs of resolutions and aggregated statistics are returned.

Read RTT Statistics **Operation:** `network_services_statistics_rtt_read` **Summary:** Get **rtt statistics** from neighbors consuming this network service. You can filter by `asn` and peer `ip`. If the `NetworkService` does not support RTT statistics, a `404` error response will be returned. ### Receiving Updates To poll for updates, you can provide a `serial` to the `after` parameter in order to only receive results with a serial greater than the one provided. All of the above filters can be applied here and allow for receiving updates for a specific peer. If no `serial` is provided the latest RTT statistics are returned. ### Event Streaming This endpoint supports streaming updates using [**Server Sent Events**](https://html.spec.whatwg.org/multipage/server-sent-events.html#server-sent-events). To subscribe to events, negotiate the response content using the HTTP header: `Accept: text/event-stream`. Filteres are applied as above.

Read Statistics Timeseries **Operation:** `network_services_statistics_timeseries_read` **Summary:** Read a `NetworkService`s aggregated timeseries. The resolution is defined by the aggregate.

Update (Deprecated) **Operation:** `network_services_update` **Summary:** **DEPRECATION NOTICE**: This operation will be removed in favor of using `PATCH` for all updates. Update a network service.

List (Query) **Operation:** `pops_list` **Summary:** List all PoPs

Read **Operation:** `pops_read` **Summary:** Get a single point of presence

Read Cancellation Policy **Operation:** `port_reservation_cancellation_policy_read` **Summary:** The cancellation-policy can be queried to answer the questions: If I cancel my subscription, *when will it be technically decommissioned*? If I cancel my subscription, *until what date will I be charged*? When the query parameter `decommision_at` is not provided it will provide the first possible cancellation date and charge period if cancelled at above date. The granularity of the date field is a day, the start and end of which are to be interpreted by the IXP (some may use UTC, some may use their local time zone).

Create **Operation:** `port_reservations_create` **Summary:** Create a new `PortReservation`. Two workflows for allocating ports is supported and dependent on the `cross_connect_initiator` property of the corresponding `product-offering`: Individual LOAs can be uploaded and downloaded for each PortAllocation using the endpoint `/port-reservations/{id}/loa`. Please refer to the internet exchange's api usage guide for implementation specific details.

Request Decommission **Operation:** `port_reservations_destroy` **Summary:** Request decommissioning the port-reservation. The associated `port` will be deallocated and removed from the `connection`.

List (Query) **Operation:** `port_reservations_list` **Summary:** List all port reservations.

Download LOA **Operation:** `port_reservations_loa_download` **Summary:** Download the *Letter Of Authorization* associated with the port-reservation. In case of a *subscriber initiated cross-connect*, it will be provided by the exchange.

Upload LOA **Operation:** `port_reservations_loa_upload` **Summary:** Upload a *Letter Of Authorization* for this `PortReservation`.

Update **Operation:** `port_reservations_partial_update` **Summary:** Update a port reservation.

Read **Operation:** `port_reservations_read` **Summary:** Retrieve a `PortReservation`.

Update (Deprecated) **Operation:** `port_reservations_update` **Summary:** **DEPRECATION NOTICE**: This operation will be removed in favor of using `PATCH` for all updates. Update a port reservation.

List (Query) **Operation:** `ports_list` **Summary:** List all ports.

Read **Operation:** `ports_read` **Summary:** Retrieve a port.

Read Statistics **Operation:** `ports_statistics_read` **Summary:** Read a `Port`s aggregated statistics. A `start` and `end` query parameter can be used to retrieve the aggregated traffic for a given window. In this case the key of the returned statistics is `custom`. With a given `start` and `end` window, the resolution for the aggregated data is chosen by the implementation. You need to check the `accuracy` attribute of the aggregate, to see if the data can be used for the desired usecase. The `accuracy` is the ratio of *total samples* to *expected samples*. If no `start` or `end` parameter is given, a sliding window is assumed and key value pairs of resolutions and aggregated statistics are returned.