A guide for systematically ordering services using the Megaport API.

In this post we’ll look at the process for systematically ordering services using the Megaport API. Currently there are four service types which can be ordered, three are widely available and the fourth is limited to partners.

• MEGAPORT
• IX
• VXC
• MEGADIRECT

The IX&#153, VXC&#153 and MEGADIRECT&#153 service types are all dependent on having an existing MEGAPORT service. First, we’ll get a list of locations that are valid for ordering to.

curl -X GET https://api.megaport.com/secure/dropdowns/locations?token=dafb8cd2-762a-4633-943b-7d5886c34124

The data returned is a list of datacentres in the format [id, name, state, country]. Now we have this information lets order a MEGAPORT at Global Switch in Sydney.

# /secure/ecommerce/megaport/order
curl -X POST -H 'Content-Type: application/json' -d
' {
"technicalContactId": "",
"megaPortProvItem": {
   "rackId":
   "DS01-99 R1",
   "opticalInterface": "",
   "speed": 10000,
   "networkServiceType": "MEGAPORT",
   "portId": "1",
   "location_id": "3" },
 "ixProvItem": {},
 "adminContactId": "",
 "companyId": 203,
 "billingContactId": "",
 "productType": "MEGAPORT",
 "customerRequestDate": "2014-12-29T14:00:00.000Z",
 "serviceName": "Test Service"
} '

 https://api.megaport.com/secure/ecommerce/megaport/order?token=dafb8cd2-762a-4633-943b-7d5886c34124

This submits the order for a MEGAPORT without any attached services however you can see in the JSON object that there is scope to order a MEGAPORT with an IX in the same request. Once we POST that to the API server we should get a response that looks something like this:

// [status, service_name, service_id]
["OK","Test Service","501"]

The provisioning process happens within the HTTP request, if an OK response is received then it’s generally safe to assume to assume that the order has been accepted. Resources are also allocated right away so a GET request to /secure/technicalservice/:serviceId will should provide useful data. There is one exception to this however, valid MEGAPORT orders will always be accepted even if the resources aren’t immediately available. Where a MEGAPORT order is accepted but the resources aren’t available, the networkService will remain in the Provisioning state and the resources property will be empty. This shouldn’t happen often but if it does someone will be in touch to provide further information.

Now we have a new MEGAPORT service, lets order a VXC.

# /secure/ecommerce/vxc/order
curl -s -XPOST -H'Content-Type: application/json' -d
' {
  "amazonDirectConnectConfigDto": {
  "type": "private",
  "asn": 65001,
  "authKey": "password1",
  "ownerAccount": "123456789123" },
  "payerMegaPortNsId": "388",
  "nonPayerMegaPortNsId": "720",
  "payerVlanId": 887,
  "nonPayerVlanId": 889,
  "payerStatus": "APPROVED",
  "rateType": "MONTHLY",
  "rollover": true,
  "speed": 100
} '

 https://api.megaport.com/secure/ecommerce/vxc/order?token=dafb8cd2-762a-4633-943b-7d5886c34124

The request above is an example of an AWS Direct Connect order. VXCs to Amazon are automatically approved however this happens in the backend in one of the post-order processing stages so the response object shows the non-payer approval stage as unassessed. A request object to order a VXC to a non-Amazon port is identical, just leave off the amazonDirectConnectConfigDto key. The way this is implementated behind the scenes will be explained in some more detail in an upcoming post on integration. The response object is a bit verbose but contains information on the service,

{
"createDate": 1419666180292,
"vxcOrderId": 267,
"payerMegaPortId": 245,
"nonPayerMegaPortId": 477,
"payerMegaPortName": "The MEGAPORT at Global Switch",
"nonPayerMegaPortName": "Amazon (ap-southeast-2) (Global Switch)",
"payerCompanyId": 203,
"nonPayerCompanyId": 117,
"salesId": null,
"payerCompanyName": "MEGAPORT",
"nonPayerCompanyName": "Amazon",
"payerMegaPortNsId": 388,
"nonPayerMegaPortNsId": 720,
"payerVlanId": 887,
"nonPayerVlanId": 889,
"payerApproverName": null,
"payerApproverId": null,
"nonPayerApproverName": null,
"nonPayerApproverId": null,
"payerApproval": null,
"nonPayerApproval": null,
"fixedTerm": true,
"duration": 1,
"rollover": true,
"name": "from The MEGAPORT at Global Switch to Amazon (ap-southeast-2) (Global Switch)",
"payerStatus": "APPROVED",
"nonPayerStatus": "UN_ASSESSED",
"speed": 100,
"distanceBand": "DATA_CENTRE",
"intercapPath": "",
"awsId": null,
"rateType": "MONTHLY",
"vxcJTechnicalServiceId": 678,
"provisionDate": 1419666180014,
"orderType": "NEW",
"monthlyDiscountAmount": null,
"discountMonths": null,
"amazonDirectConnectConfigDto": null,
"rate": null,
"setup": null
}

Conclusion

Today we covered the service types that are available and how to place orders for the various service types. In the next post we’ll look at how the billing systems work, what payment options we have and how to generate some simple reports.

• API Highlight: Introduction