An Introduction to APIs for MSPs

Think about systems and workflows that are universal, like the ones that manage commercial aviation.

Whether you fly United, Air France, or Emirates, all of these airlines need to be able to communicate with each other for a number of different purposes, from layovers and baggage transfers to security.

But under the hood, each airline’s systems are architected slightly differently, with different software, databases, and other key pieces of infrastructure. How can we get these systems to talk to each other?

They may not natively speak the same language. But through some careful planning and collaboration between the maintainers of each platform, a common set of instructions, inputs, and outputs can be agreed upon to remove the complexity and uncertainty of one system telling another one what to do.

What’s an API?

API stands for application programming interface. (For a nitty gritty technical explanation, try this API for Beginners video). But really, all you need to know for now is that an API is a clearly defined set of instructions that defines how one system can interact with another.

There are different styles of APIs that have gained and lost prominence over the last few decades. For the purposes of our discussion, we’ll talk about Representative State Transfer (REST-ful) APIs, which have emerged as this decade’s most popular web service API. There are many other more developer-centric APIs, like library or class-based APIs, that we’ll keep out of scope.

Modern APIs expose what are called endpoints, or paths that represent an object or collection of objects, say, the hostname of your largest client’s main firewall.

Each endpoint typically allows for (at least one of) a set of CRUD actions. CRUD stands for create, read, update, and delete. In our hostname example, using an API, you could invoke an action to create a new hostname, read the existing hostname, update the existing hostname, or delete the existing hostname.

Until now, the network’s been stuck in the Stone Age

APIs have deeply penetrated the endpoint space of servers and workstations. Take a Windows application developer. In each area where an application needs to plug or hook into Windows, the developer can use an appropriate set of API endpoints.

But to date, APIs have been few and far between on the network.

Recall some of the legacy methods we’ve been using over the years to communicate with network devices:

• CLI
• Web GUIs
• SNMP
• Vendor-specific apps

Think about just how fragile and frustrating these communication methods can be to use. Syntax can change from version to version of firmware. With different hardware configurations, you need to reference different components differently. Modern web-based technologies like JavaScript prevent easy scraping of data. SNMP implementations require in-depth knowledge of how to navigate the maze of MIBs and OIDs—not to mention there’s a large amount of incomplete and incorrect data that surfaces through SNMP.

Performing a “simple” task like adding a rule on a firewall has traditionally been cumbersome. But with a clearly defined set of API endpoints, I could update a set of firewall rules without having to navigate through a CLI configuration hierarchy and issue a series of commands.

Here’s an example of a cURL request I could make to the Meraki Dashboard API:

curl -L -H 'X-Cisco-Meraki-API-Key: ' -X PUT -H 
'Content-Type: application/json' --data-binary 
'{"rules":[{"comment":"A note about the rule", 
"policy":"deny", "protocol":"tcp", "destPort":"80,443", "destCidr":"192.168.1.0/24,192.168.2.0/24", "srcPort":"any", 
"srcCidr":"any", 
"syslogEnabled":true}],"syslogDefaultRule":true}' 'https://api.meraki.com/organizations/[organizationId]/vpnFirewallRules'

Within this relatively small request, we’re specifying the following:

• comment
• description of the rule (optional)
• policy
• allow or deny traffic specified by this rule
• protocol
• type of protocol (must be tcp, udp, icmp or any)
• srcPort
• comma-separated list of source port(s)
• srcCidr
• comma-separated list of source IP address(es)
• destPort
• comma-separated list of destination port(s)
• destCidr
• comma-separated list of destination IP address(es)
• syslogEnabled
• log this rule to syslog

All done within a single command. How would this look on the CLI?

We’d have to craft something like this (for a Juniper SRX):

set interfaces fe-0/0/0 unit 0 family inet filter input blocked.IP
set interfaces fe-0/0/0 unit 0 family inet filter output blocked.IP

set policy-options prefix-list block.outbound 192.168.1.1/24
set policy-options prefix-list block.outbound 192.168.2.1/24
set policy-options prefix-list unblock.outbound

set security log mode stream
set security log source-address 192.168.1.254
set security log stream Server format syslog
set security log stream Server host 192.168.1.1
set security log stream Server host port 123

set firewall family inet filter blocked.IP term 1 from prefix-list block.outbound
set firewall family inet filter blocked.IP term 1 from prefix-list unblock.outbound except
set firewall family inet filter blocked.IP term 1 then syslog
set firewall family inet filter blocked.IP term 1 then discard
set firewall family inet filter blocked.IP term 2 then accept

See how much more concise the API query is?

The new age of APIs in the SMB network space

We all know the network layer is fundamental as a base for applications and services to ride on.

For the longest time, we’ve seen servers, workstations, and even newer device types like smartphones, give developers increasingly sophisticated and data-driven ways to interface with their operating systems.

But network gear like your routers, switches, and firewalls have been relegated to using archaic methods like the command line interface (CLI), a web GUI that requires some annoying plugin like Java or Flash to show all content correctly, or a native application like Cisco ASDM to perform relevant configuration.

More recently, though, network vendors have begun exposing APIs, either as a supplement or exclusive replacement to the CLI. (GUIs are here to stay).

Vendors with a cloud management component to their offering, like Meraki and Datto / OpenMesh, have developer APIs. We’ve also seen some on-prem products from the likes of Barracuda and Sophos that allow interaction with devices using an API.

These APIs make possible some powerful automated workflows, such as bulk resetting passwords, initiating firmware upgrades, and provisioning VLANs for a new application (like voice or video) throughout the network stack in a matter of seconds instead of minutes or hours. As a result, APIs free up your technicians to devote their time and expertise to helping you scale your business.

What does this mean for MSPs?

When replacing or augmenting certain areas of your MSP tool stack, look for products and vendors that have opened up their platform with APIs. This will give you the flexibility of integrating other products into your stack, and potentially developing automation to eliminate repetitive tasks that are better left to a machine.

The more information you can extract, transform, and load from one system into another, the more you open up possibilities for automation and more seamless workflows. Open APIs promote interoperability from one vendor toolset to another, allowing tight integrations.

The end goal here is automation nirvana, with historically strenuous and humanly unscalable tasks being automated, allowing you to focus on growing your MSP practice instead of poring over spreadsheets and attempting manual reconciliation.

What’s Auvik’s API strategy?

At Auvik, we’re huge advocates for the potential breadth and depth of data injection and extraction that APIs allow. We’re working on a number of APIs that will allow our partners and third-party vendors to tightly integrate with Auvik. Watch for developments throughout 2018.