@itentialopensource/adapter-velocloud_orchestrator

openapi: 3.0.0 info: title: VeloCloud Orchestrator API description: > ## <p>The VeloCloud Orchestrator (VCO) powers the management plane in the VMware SD-WAN solution. It offers a broad range of configuration, monitoring and troubleshooting functionality to service providers and enterprises alike. The principal web service with which users interact in order to exercise this functionality is called the <strong>VCO Portal</strong>.</p> <h2>The VCO Portal</h2> <p>The VCO Portal allows network administrators (or scripts and applications acting on their behalf) to manage network and device configuration and query current or historical network and device state. API clients may interact with the Portal via a JSON-RPC interface or a REST-like interface. It is possible to invoke all of the methods described in this document using either interface; there is no Portal functionality for which access is constrained exclusively to either JSON-RPC clients or REST-like ones.</p> <p>Both interfaces accept <strong>exclusively HTTP POST</strong> requests. Both also expect that request bodies, when present, are JSON-formatted -- consistent with RFC 2616, clients are furthermore expected to formally assert where this is the case using the `Content-Type` request header, e.g. `Content-Type: application/json`.</p> <h3>JSON-RPC Interface</h3> <p>The JSON-RPC API accepts calls via the `/portal` URL path (e.g. vco.velocloud.net/portal). Consistent with <a href="https://www.jsonrpc.org/specification">v2.0 of the JSON-RPC specification</a>, the API expects JSON-encoded request payloads that consist of a method name (`method`), a parameters object (`params`), a user-specified unique request identifier (`id`, by convention an integer such as a millisecond-precision epoch timestamp), and a JSON-RPC specification version identifier (`jsonrpc`). The VCO supports only the 2.0 iteration of the JSON-RPC specification, and so the value of the `jsonrpc` parameter should always be the string `"2.0"`. A sample request follows:</p> <pre>curl --header 'Content-Type: application/json' --data '{"jsonrpc":"2.0","method":"event/getEnterpriseEvents","params":{"enterpriseId":1},"id":1}' --cookie cookies.txt -X POST https://vco.velocloud.net/portal/</pre> <h3>REST-like Interface</h3> <p>The REST-like interface eliminates some of the protocol "overhead" imposed by the JSON-RPC interface, and may feel more familiar to those familiar with URL-based REST semantics. It also offers a greater degree of interoperability with a range of client-side tools designed for use with traditional REST APIs. The interface is accessible via the `/portal/rest/` base path. In processing REST-like requests, the VCO parses the method name from the portion of the URL path that follows the base path. The request body need contain only the method parameters, e.g.:</p> <pre>curl --header 'Content-Type: application/json' --data '{"enterpriseId":1}' --cookie cookies.txt -X POST https://vco.velocloud.net/portal/rest/event/getEnterpriseEvents</pre> <h2>Authentication</h2> <p>The VCO API supports cookie-based authentication. Most programming languages and HTTP client applications expose libraries or options that facilitate the management and use of session cookies, which clients are free to leverage in working with the VCO (e.g. curl exposes the `--cookie-jar` and `--cookie` options, Python's `requests` library <a href="https://requests.readthedocs.io/en/master/user/advanced/#session-objects">exposes a Session interface</a>, etc.). Numerous code samples, wherein authentication is demonstrated in a variety of programming languages, are available via <a href="https://code.vmware.com/samples?categories=Sample&keywords=velocloud">VMware Sample Exchange</a>.</p> <p>Clients initiate sessions by invoking either the `login/enterpriseLogin` or the `login/operatorLogin` method, depending on the user type associated with the client's credentials (Partner and Customer Admins should use the former method, and Operator Admins the latter). In the event of a successful authentication call, the API responds with an HTTP 200 status code and embeds a `velocloud.session` cookie in a `Set-Cookie` response header. When authentication is unsuccessful, the API responds with an HTTP 302 status code and includes a short message elaborating on the failure in a `velocloud.message` cookie. A sample authentication call is demonstrated with the curl command-line utility below (response truncated for brevity):</p> <pre>curl --cookie-jar /tmp/cookie.txt -i -X POST https://vco.velocloud.net/portal/rest/login/enterpriseLogin --data '{"username":"admin@velocloud.net","password":"'$SECRET'"}'<br/>< HTTP/1.1 200 OK<br/>< Set-Cookie: velocloud.session=<token>; <attributes></pre> <p>Once a client has successfully retrieved a session cookie, it may begin to make API calls to API methods that require authentication by embedding the `velocloud.session` cookie in a `Cookie` request header (programming languages and other client utilities typically provide interfaces that simplify this).</p> <p>Session cookies typically expire after a period of 24 hours (though liftetimes are configurable and may vary across VCO deployments). It is considered best practice to invalidate cookies whenever they are no longer required by initiating a call to the `logout` API method:</p> <pre>curl --cookie /tmp/cookie.txt -X POST https://vco.velocloud.net/portal/rest/logout</pre> <h2>Data Model & Terminology</h2> <p>The terminology of the VCO API schema doesn't always align with the terminology of the Web Console. Consider this a "cheat sheat" to aid in interpreting API constructs:</p> <ul><li><strong>Enterprise</strong>: Customer</li><li><strong>Enterprise Proxy</strong>: Partner</li><li><strong>Configuration</strong>: Device configurations are modeled in the API schema as a composition of "Configuration" entities. There are effectively three distinct types of Configurations: Operator Profiles (also referred to as "Software Images"), Customers Profiles (referred to in the API schema as "Enterprise Configurations"), and Edge-Specific Profiles.</li><li><strong>Configuration Module</strong>: Each configuration is composed of a set of modules (e.g. `deviceSettings`, `QOS`, `firewall`, `controlPlane`, etc.), wherein the actual configuration `data` resides. In the current version of the API, configuration changes must always be applied at the module level (i.e. via calls to the `configuration/updateConfigurationModule` API method). Partial updates on specific sections of Configuration Module `data` are not (yet) supported.</li><li><strong>Refs</strong>: `refs` are associations between a Network Service (e.g. DNS providers, authentication services, VPN hubs, etc.) and a Configuration (more precisely, a Configuration Module). They should generally be treated as read-only.</li></ul> <h2>Common Parameters</h2> <p>A few parameters appear repeatedly throughout the API schema:</p> <h3>`enterpriseId`</h3> <p>The Portal API enforces that an `enterpriseId` parameter is <strong>required on any request initiated by an Operator or Partner Administrator that accesses, or operates upon, a Customer-managed resource</strong> (e.g. Edges, Profiles, network services). `enterpriseId` is never required for API calls initiated by Customer Administrators (in such cases it is inferred based on the user's credential).</p> <h3>`enterpriseProxyId`</h3> <p>Similar to the `enterpriseId` parameter, the Portal API enforces that an `enterpriseProxyId` parameter is <strong>required on any request initiated by an Operator Administrator that accesses, or operates upon, a Partner-managed resource</strong> (e.g. Partner Events, Partner Gateway Pools, etc.). `enterpriseProxyId` is never required for API calls initiated by Partner Administrators (in such cases it is inferred based on the user's credential).</p> <h3>`with`</h3> <p>Many "fetch" API methods support a `with` parameter, which allows the user to optionally resolve related entities. `recentLinks` is a special instance of one such option that is supported by methods that fetch Edges, which will cause the API to resolve WAN links for which activity has been recorded in the last 24 hours. This should generally be preferred to the `links` option on methods where it is supported.</p> <h3>`interval`</h3> <p>Many methods, such as those that query events or volumetric flow data, support a query `interval`. The default query interval, inferred by the server when none is otherwise specified, is the most recent 12 hour period.</p> <p>The VCO exposes time series data (e.g. device system health metrics such as CPU and memory usage, network metrics such as latency/jitter/loss, volumetric traffic flow data) via various API methods that accept query intervals. By default, Edges and Gateways report new statistics to the Orchestrator every five minutes. Due to various factors (clock drift, network jitter, server-side processing delays), statistics associated with a given interval beginning at time `t` are often not reflected in API output until time `t + 10 minutes`. As such, we do not recommend using query intervals smaller than 10 minutes in time for these methods.</p> <h2>Datetimes</h2> <p>The Orchestrator API uses UTC time universally. Whenever a method request schema calls for a datetime value, and whenever a response includes a datetime value, the timezone should be inferred to be UTC.</p> <p>The VCO accepts the following datetime formats:</p> <ul><li>13-digit millisecond-precision epoch timestamps (e.g. `1500000000000`)</li><li>Datetime strings formatted consistently with RFC 3339. (e.g. `"2017-01-01T00:00:00.000Z"`)</li></ul> <br> contact: name: VMware SD-WAN by VeloCloud url: https://www.vmware.com/products/sd-wan-by-velocloud.html version: '3.3.2' servers: - url: https://{defaultHost} variables: defaultHost: default: www.example.com/portal/rest paths: /login/operatorLogin: post: tags: - all - login summary: login_operator_login description: "Authenticates an operator user and, upon successful login, returns a velocloud.session cookie. Pass this session cookie in the authentication header in subsequent VCO calls.\n If you are using an HTTP client (e.g. Postman) that is configured to automatically follow HTTP redirects, a successful authentication request will cause your client to follow an HTTP 302 redirect to the portal 'Home' web page. Your session cookie can then be used to make VCO API calls. \n Note that session cookies expire after a period of time specified in the VCO configuration (default is 24 hours)." operationId: login_operator_login parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/auth_object' required: true responses: '200': description: If you are using an HTTP client that is configured to automatically follow HTTP redirects (e.g. Postman), a successful authentication request will cause your client to follow a HTTP 302 redirect to the portal 'Home' web page. Your session cookie may then be used to make API calls. headers: {} content: {} '302': description: An HTTP 302 response is returned on both successful and failed authentication attempts. If the response includes a Set-Cookie header specifying a non-empty velocloud.session cookie, authentication was successful and this cookie may be used to make API calls. headers: {} content: {} deprecated: false /login/enterpriseLogin: post: tags: - all - login summary: login_enterprise_login description: >- Authenticates an enterprise or partner (MSP) user and, upon successful login, returns a velocloud.session cookie. Pass this session cookie in the authentication header in subsequent VCO calls. If you are using an HTTP client (e.g. Postman) that is configured to automatically follow HTTP redirects, a successful authentication request will cause your client to follow an HTTP 302 redirect to the portal 'Home' web page. Your session cookie can then be used to make VCO API calls. Note that session cookies expire after a period of time specified in the VCO configuration (default is 24 hours). operationId: login_enterprise_login parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/auth_object' required: true responses: '200': description: If you are using an HTTP client that is configured to automatically follow HTTP redirects (e.g. Postman), a successful authentication request will cause your client to follow an HTTP 302 redirect to the portal 'Home' web page. Your session cookie may then be used to make API calls. headers: {} content: {} '302': description: An HTTP 302 response is returned on both successful and failed authentication attempts. If the response includes a Set-Cookie header specifying a non-empty velocloud.session cookie, authentication was successful and this cookie may be used to make API calls. headers: {} content: {} deprecated: false /logout: post: tags: - all - login summary: logout description: Logs out the VCO API user and invalidates the session cookie. operationId: logout parameters: [] responses: '200': description: If you are using an HTTP client that is configured to automatically follow HTTP redirects (e.g. Postman), a successful logout request will cause your client to follow an HTTP 302 redirect to the portal login web page. headers: {} content: {} '302': description: An HTTP 302 (redirect) response is returned on both successful and failed logout attempts. headers: {} content: {} deprecated: false /meta/{apiPath}: post: tags: - all - meta summary: meta description: Gets the Swagger specification for any VCO API call. operationId: meta parameters: - name: apiPath in: path description: the path to another api method, starting after /rest/ required: true style: simple schema: type: string responses: '200': description: Request successful headers: {} content: application/json: schema: $ref: '#/components/schemas/metaResponse' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: true /configuration/cloneEnterpriseTemplate: post: tags: - all - configuration summary: configuration_clone_enterprise_template description: >- Creates a new enterprise configuration from the enterprise default configuration. On success, returns the `id` of the newly created configuration object. Privileges required: `CREATE` `ENTERPRISE_PROFILE`, or `CREATE` `OPERATOR_PROFILE` operationId: configuration_clone_enterprise_template parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/configuration_clone_enterprise_template' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/configuration_clone_enterprise_template_result' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /configuration/deleteConfiguration: post: tags: - all - configuration summary: configuration_delete_configuration description: >- Deletes the specified configuration profile (by `id`). On success, returns an object indicating the number of objects (rows) deleted (1 or 0). Privileges required: `DELETE` `ENTERPRISE_PROFILE`, or `DELETE` `OPERATOR_PROFILE` operationId: configuration_delete_configuration parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/configuration_delete_configuration' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/deletion_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /configuration/getConfiguration: post: tags: - all - configuration summary: configuration_get_configuration description: >- Gets the specified configuration profile, optionally with module details. Privileges required: `READ` `ENTERPRISE_PROFILE`, or `READ` `OPERATOR_PROFILE` operationId: configuration_get_configuration parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/configuration_get_configuration' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/configuration_get_configuration_result' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /configuration/getIdentifiableApplications: post: tags: - all - configuration summary: configuration_get_identifiable_applications description: >- Gets all applications that are identifiable through DPI. If called from an operator or MSP context, then `enterpriseId` is required. Privileges required: `READ` `ENTERPRISE_PROFILE` operationId: configuration_get_identifiable_applications parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/enterprise_get_enterprise_configurations_with_policies' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/configuration_get_identifiable_applications_result' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /configuration/getRoutableApplications: post: tags: - all - configuration summary: configuration_get_routable_applications description: >- Gets all applications that are first packet routable. If called from an operator or MSP context, then `enterpriseId` is required.Optionally, specify `edgeId` to get the map for a specific Edge. Privileges required: `VIEW_FLOW_STATS` `undefined` operationId: configuration_get_routable_applications parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/configuration_get_routable_applications' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/configuration_get_routable_applications_result' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /disasterRecovery/configureActiveForReplication: post: tags: - all - disasterRecovery summary: disaster_recovery_configure_active_for_replication description: >- Configures the current Orchestrator to be active and the specified Orchestrator to be standby for Orchestrator disaster recovery replication. Required attributes: 1) `standbyList`, a single-entry array containing the `standbyAddress` and `standbyUuid`, 2) `drVCOUser`, a Orchestrator super user available on both the active and standby VCOs, and 3) `drVCOPassword`, the password of `drVCOUser` on the standby Orchestrator (unless the `autoConfigStandby` option is specified as `false`). The call sets up the active Orchestrator to allow replication from the standby and then (unless `autoConfigStandby` is `false`) makes a `transitionToStandby` API call to the specified standby, expected to have been previously placed in `STANDBY_CANDIDATE` state via `prepareForStandby`. After this call, the active and standby VCOs should be polled via `getReplicationStatus` until they both reach `STANDBY_RUNNING` `drState` (or a configuration error is reported). (Note: `drVCOPassword` is not persisted.) Privileges required: `CREATE` `REPLICATION` operationId: disaster_recovery_configure_active_for_replication parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/disaster_recovery_configure_active_for_replication' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/rows_modified_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /disasterRecovery/demoteActive: post: tags: - all - disasterRecovery summary: disaster_recovery_demote_active description: >- Demotes the current VCO from active to zombie. No input parameters are required. The active server is expected to be in the `drState` `FAILURE_GET_STANDBY_STATUS` or `FAILURE_MYSQL_ACTIVE_STATUS`, meaning that DR protection had been engaged (with the last successful replication status observed at `lastDRProtectedTime`) but that active failed a health check since that time. If the active server is in the `drState` `STANDBY_RUNNING`, meaning that it has detected no problems in interacting with the standby server, the operator can force demotion of the active using the optional `force` parameter passed with value of `true`; in this case, the operator must ensure that the standby server has already been successfully promoted. Privileges required: `CREATE` `REPLICATION` operationId: disaster_recovery_demote_active parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/disaster_recovery_demote_active' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/rows_modified_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /disasterRecovery/getReplicationBlob: post: tags: - all - disasterRecovery summary: disaster_recovery_get_replication_blob description: >- Gets from the active Orchestrator the blob needed to configure replication on the standby. Used only when `configureActiveForReplication` was called with `autoConfigStandby` set to `false` [`true` by default]. Privileges required: `CREATE` `REPLICATION` operationId: disaster_recovery_get_replication_blob parameters: [] requestBody: description: '' content: text/plain: schema: type: object required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/disaster_recovery_get_replication_blob_result' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /disasterRecovery/getReplicationStatus: post: tags: - all - disasterRecovery summary: disaster_recovery_get_replication_status description: >- Gets the disaster recovery replication status, optionally with client contact, state transition history, and storage information. No input parameters are required. Can optionally specify one or more of the following `with` parameters: `clientContact`, `clientCount`, `stateHistory`, and `storageInfo`. Privileges required: `READ` `REPLICATION` operationId: disaster_recovery_get_replication_status parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/disaster_recovery_get_replication_status' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/disaster_recovery_get_replication_status_result' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /disasterRecovery/prepareForStandby: post: tags: - all - disasterRecovery summary: disaster_recovery_prepare_for_standby description: >- Transitions the current Orchestrator to a quiesced state, ready to be configured as a standby system. No input parameters are required. After this call, the Orchestrator will be restarted in standby mode. The caller should subsequently poll `getReplicationStatus` until `drState` is `STANDBY_CANDIDATE`. This is the first step in configuring Orchestrator disaster recovery. Privileges required: `CREATE` `REPLICATION` operationId: disaster_recovery_prepare_for_standby parameters: [] requestBody: description: '' content: text/plain: schema: type: object required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/rows_modified_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /disasterRecovery/promoteStandbyToActive: post: tags: - all - disasterRecovery summary: disaster_recovery_promote_standby_to_active description: "Promotes the current server to take over as the single standalone VCO. The current server is expected to be a standby in the `drState` `FAILURE_MYSQL_STANDBY_STATUS`, meaning that DR protection had been engaged (with the last successful replication status observed at `lastDRProtectedTime`), but that standby has been unable to replicate since that time. \n If the standby server is in the `drState` `STANDBY_RUNNING`, meaning that it has detected no problems in replicating from the active server, the operator can force promotion of the standby using the optional `force` parameter passed with a value of `true`. In this case, the standby server will call `demoteActive/force` on the active server. The operator should, if possible, ensure that the formerly active server is demoted by running `demoteServer` directly on that server if the standby server was unable to do so successfully.\n\nPrivileges required:\n\n`CREATE` `REPLICATION`" operationId: disaster_recovery_promote_standby_to_active parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/disaster_recovery_promote_standby_to_active' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/rows_modified_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /disasterRecovery/removeStandby: post: tags: - all - disasterRecovery summary: disaster_recovery_remove_standby description: >- Removes disaster recovery on the current server. In addition, makes a best-effort call to `removeStandby` on the paired disaster recovery server. No input parameters are required. Privileges required: `CREATE` `REPLICATION` operationId: disaster_recovery_remove_standby parameters: [] requestBody: description: '' content: text/plain: schema: type: object required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/rows_modified_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /disasterRecovery/transitionToStandby: post: tags: - all - disasterRecovery summary: disaster_recovery_transition_to_standby description: >- Configures the current Orchestrator to transition to standby in a disaster recovery active/standby pair. Requires the `activeAccessFromStandby` parameter that contains the data needed to configure standby. This data is produced by `configureActiveForReplication`, which by default automatically calls `transitionToStandby`; an explicit call is needed (with a blob obtained from `getReplicationBlob`), only if `configureActiveForReplication` is called with `autoConfigStandby` set to `false`. Privileges required: `CREATE` `REPLICATION` operationId: disaster_recovery_transition_to_standby parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/disaster_recovery_transition_to_standby' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/rows_modified_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /edge/deleteEdge: post: tags: - all - edge summary: edge_delete_edge description: >- Deletes the specified Edge(s) (by `id` or an array of `ids`). Privileges required: `DELETE` `EDGE` operationId: edge_delete_edge parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/edge_delete_edge' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: type: array items: $ref: '#/components/schemas/deletion_confirmation' description: '' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /edge/deleteEdgeBgpNeighborRecords: post: tags: - all - edge summary: edge_delete_edge_bgp_neighbor_records description: >- Deletes BGP record(s) matching the specified record keys (`neighborIp`) on the Edges with the specified `edgeId`s, if they exist. Privileges required: `DELETE` `NETWORK_SERVICE` operationId: edge_delete_edge_bgp_neighbor_records parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/edge_delete_edge_bgp_neighbor_records' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/deletion_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /edge/setEdgeEnterpriseConfiguration: post: tags: - all - edge summary: edge_set_edge_enterprise_configuration description: >- Sets the enterprise configuration for the specified Edge (by `edgeId`). Privileges required: `UPDATE` `EDGE` `UPDATE` `ENTERPRISE_PROFILE` operationId: edge_set_edge_enterprise_configuration parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/edge_set_edge_enterprise_configuration' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/insertion_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /edge/setEdgeHandOffGateways: post: tags: - all - edge summary: edge_set_edge_hand_off_gateways description: >- Sets the on-premise hand off gateways for the specified Edge (by `edgeId`). A primary and secondary gateway are defined. The primary is required, the secondary is optional. Moves all existing Edge-gateway hand-off relationships and replaces them with the specified primary and secondary gateways. Privileges required: `UPDATE` `EDGE` operationId: edge_set_edge_hand_off_gateways parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/edge_set_edge_hand_off_gateways' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/rows_modified_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /edge/setEdgeOperatorConfiguration: post: tags: - all - edge summary: edge_set_edge_operator_configuration description: >- Sets the operator configuration for the specified Edge (by `edgeId`). This overrides any enterprise-assigned operator configuration and the network default operator configuration. Privileges required: `UPDATE` `EDGE` `READ` `OPERATOR_PROFILE` operationId: edge_set_edge_operator_configuration parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/edge_set_edge_operator_configuration' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/insertion_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /enterprise/deleteEnterprise: post: tags: - all - enterprise summary: enterprise_delete_enterprise description: >- Deletes the specified enterprise (by `id` or `enterpriseId`). Privileges required: `DELETE` `ENTERPRISE` operationId: enterprise_delete_enterprise parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/enterprise_get_enterprise_configurations_with_policies' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/deletion_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /enterprise/deleteEnterpriseGatewayRecords: post: tags: - all - enterprise summary: enterprise_delete_enterprise_gateway_records description: >- Deletes the enterprise gateway BGP neighbor record(s) matching the specified gateway id(s) (`gatewayId`) and neighbor IP addresses (`neighborIp`). Privileges required: `DELETE` `NETWORK_SERVICE` operationId: enterprise_delete_enterprise_gateway_records parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/enterprise_delete_enterprise_gateway_records' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/deletion_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /enterprise/deleteEnterpriseNetworkAllocation: post: tags: - all - enterprise summary: enterprise_delete_enterprise_network_allocation description: >- Deletes the specified enterprise network allocation (by `id`). Privileges required: `DELETE` `NETWORK_ALLOCATION` operationId: enterprise_delete_enterprise_network_allocation parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/enterprise_delete_enterprise_network_allocation' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/deletion_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: schema: $ref: '#/components/schemas/error' deprecated: false /enterprise/deleteEnterpriseNetworkSegment: post: tags: - all - enterprise summary: enterprise_delete_enterprise_network_segment description: >- Delete an enterprise network segment, by id. Privileges required: `DELETE` `NETWORK_ALLOCATION` operationId: enterprise_delete_enterprise_network_segment parameters: [] requestBody: description: '' content: application/json: schema: $ref: '#/components/schemas/enterprise_delete_enterprise_network_segment' required: true responses: '200': description: Request was successfully processed headers: {} content: application/json: schema: $ref: '#/components/schemas/deletion_confirmation' '400': description: 'Invalid Request: Please check your request schema' headers: {} content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Error parsing or processing request headers: {} content: application/json: sc