API Support News

These are the news items I've curated in my monitoring of the API space that have some relevance to the API definition conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is testing their APIs, going beyond just monitoring and understand the details of each request and response.

The Plivo Support Portal And Knowledge Base

I’m always watching out for how existing API providers are shifting up their support strategies in their communities as part of my work. This means staying into tune with their communications, which includes processing their email newsletters and developer updates. Staying aware of what is actually working, and what is not working, based upon active API service providers who are finding ways to make it all work.

Plivo opted out to phase out direct emails at the end of the month, and pushing developers to use the Plivo support portal, and the ticketing system. The support portal provides a knowledge base which provides a base of self-service support before any developer actually uses the support ticketing system to:

  • Create, manage, respond to and check the status of your support ticket(s)
  • Select improved ticket categories for more efficient ticket routing and faster resolution
  • Receive resolution suggestions from our knowledge base before you submit a ticket to help decrease resolution time

Email only support isn’t always the most optimal way of handling support, and using a ticketing system definitely provides a nice trail to follow for both sides of the conversations. The central ticketing system also provides a nice source of content to feed into the self-service support knowledge base, keeping self-service support in sync with direct support activity.

I’m going to continue to track on which API providers offer a ticketing solution, as well as a knowledge base. I’m feeling like these are what I’m going to recommend to new API providers as what I consider to be default support building blocks that EVERY API platform should be starting with, covering the self-service and direct support requirements of a platform. I’m going to start pushing 1-3 support solutions like ZenDesk, also giving API providers some options when it comes to quickly delivering adequate support for their platforms.

Tweeting Out Your API Forum Conversations

It is a lot of work to keep the API evangelism drumbeat going each day on your blog, Twitter, and other social media channels you use for your API operations. Each Tweet, Facebook or LinkedIn Post is one possible signal that might reach existing developers, or possibly reach a potentially new API consumer–educating them about what your API does.

My friends over at the Oxford Dictionaries APIs are getting really good at this API evangelism song and dance, and one of the tactics in their toolbox is regularly Tweeting out relevant threads from their API forum. It is a great way to expose conversations that are going on within your API support forum, and help make other developers aware that these conversations are going on in a way that will also boost your overall SEO, making your API support operations more visible to the public.

Another benefit of sending out these regular API signals is that there is always the potential that I will write up what you are doing, and you’ll get the additional exposure of being on API Evangelist. When people ask me what is the #1 thing they can do to be more successful with evangelism for their API, it is always consistency. Regular, consistent drumbeats about what is going on with your platform, the problems it solves is always the best way to make sure your valuable API resources will be found and put to use in meaningful ways.

The Support Elements Of Your API Service Level Agreement

Zendesk gave me some valuable building blocks to add to both my API support and API service level agreement research, with their support SLA. This is why I keep an eye on not just how API providers are handling their support, but also how leading support software as a service API providers are setting the bar for how we do support.

The Zendesk support SLA provides us with some valuable information about setting a service level objective, developing support SLA workflow, dealing with a breach, and even some key performance indicators (KPIs) to help you measure success. I will be taking the bullet points from each area and adding to the overlap of my API support and service level research, and I’ll even begin flushing out my API breach research with its first handful of building blocks regarding how to handle a really bad situation.

I’m seeing an uptick in the number of SLAs with leading API providers, so it makes sense to start considering how other aspects of API operations should be reflected in our API service level agreements. How you support and communicate with your customers can be just as important as the technical bullets of your SLA. Most of the SLAs I’ve read in the API space focus on the technical, business, and legal considerations of integration, but Zendesk reminds us of the actual human elements of setting and meeting a specific level of service when it comes to API integration.

The Depth And Dimensions Of Monitoring API Operations

When I play with my Hitch service I am always left thinking about the many dimensions of API monitoring. When you talk about API monitoring in the tech sector conversations almost always start with the API providers and the technical details monitoring of individual APIs. Hopefully, these discussions also focus on API monitoring from the API consumers point of view, but I wanted to also shine a light on companies like Hitch who are adding an additional dimension from the API service provider view of things–which is closer to my vantage point as an analyst.

I am an advisor to Hitch because they are a different breed of API monitoring service, that isn’t just focused on the APIs. Hitch brings in the wider view of monitoring the entire operations of an API–if documentation changes, an SDK on Github, or update via Twitter, or a pricing change, you get alerted. As a developer I enjoy being made aware of what is going on across operations, keeping me in tune with not just the technical, but also the business and politics of API platform operations.

Another reason I like Hitch, and really the reason behind me writing this post, is that they are helping API providers think about the bigger picture of API monitoring. Helping them think deeply, as well as getting their shit together when it comes to regularly sending out the critical signals us API consumers are tuning into. When you are down in the trenches of operating an API at a large company, it is easy to get caught up in the internal vacuum, forgetting to properly communicate and support your community–Hitch helps keep this bubble from forming, assisting you in keeping an external focus on your community.

If you are just embarking on your API journey I recommend tuning into API Evangelist first. ;-) However, if you are unsure of how to properly communicate and support your community I recommend you talk to the Hitch team. They’ll help get you up to speed on the best practices when it comes to API operations, and understand how to send the right signals to your community–something that will make or break your API efforts, so please don’t ignore it.

Disclosure: I am an advisor for Hitch, and they are my friends.

Heavier Investment In API Training Will Be Necessary


I was learning about the virtual classes that Github are offering, as I was working on some basic API curriculum for some of my clients, and I was reminded of how important training and education is when it comes to technological adoption. Not everyone learns the same way, and not everyone is an autodidact, and providing training around any technology, platform, or service your company, institution, or government agency is adopting is important.

If you look at the historic spending of leading API companies like Apigee, you’ll see a large chunk of the budget going to educating and bringing would be or existing clients up to speed with the technology in play. Training and education will be a significant portion of each of the trends you see in play like DevOps, Microservices, and Serverless. A core aspect of all of these movements hinges on unwinding legacy technical debt and moving often large groups of people forward with a new way of doing things–if education isn’t a significant portion of your strategy, you will fail.

If you see any interesting API training out there on LinkedIn (Lynda), or on the open web, please let me know, I’d like to start curating more resources for people to use. I am also working with groups to develop their own internal API training and curriculum to match not just the wider API space, but also what is going on internally within an organization. In coming months I will also be going through each of my research areas that might help API providers think about how they are going to tackle API education and help my readers understand that a heavier investment in API training will be necessary to steer the ship where you want it to go.

Google Support Buttons

I talked about the gap between developer relations and support at Google, something that Sam Ramji (@sramji) has acknowledged is being worked on. Support for a single API can be a lot of work and is something that is exponentially harder with each API and developer to add to your operations, and after looking through 75 of the Google APIs this weekend, you see evidence that Google is working on it.

While there are many Google APIs that still have sub-standard support for their APIs, when you look at Google Sheets you start seeing evidence of their evolved approach to support, with a consistent set of buttons that tackle many of the common areas of API support. For general questions, Google provides two buttons linked to StackOverflow:

The search just drops you into Stack Overflow, with the tag "google sheets api", and the ask a new question drops you into the Stack Overflow submit new question form. For bug reporting, they provide a similar set of buttons:

The search and report bug buttons drop you into the Google Code issues page for Google Sheets, leveraging the issues management for the Gooogle Code repository--something that can just as easily be done with Github issues. Then lastly, they provide a third set of buttons when you are looking to submit a feature:

Even though there is a typo on the first button, they also leverage Google Code issue management to handle all feature requests. Obviously working to centralize bug and feature reporting, and support management using Google Code--something I do across all my API projects using Github organizations, repositories, and their issue management. I'm guessing Google Support is tapping into Google Code to tackle support across projects at scale.

These support buttons may seem trivial, but they represent a more consistent approach by the API giant to be consistent in how they approach support across their API offerings--something that can go a long way in my experience. It gives your API consumers a familiar and intuitive way to ask questions, submit bugs, and suggest new features. Equally as important, I'm hoping it is also giving Google a consistent way to tackle support for their APIs in a meaningful way, that meets the needs of their API consumers.

The Relationship Between Dev Relations And Support

I saw an interesting chasm emerge while at a Google Community Summit this last week, while I heard their support team talk, as well as their developer relations team discuss what they were up to. During the discussion, one of the companies presents discussed how their overall experience with the developer relations team has been amazing, their experience with support has widely been a pretty bad experience--revealing a potential gap between the two teams.

This is a pretty common gap I've seen with many other API platforms. The developer relations team is all about getting the word out, and encouraging platform usage and support teams are there to be the front line for support and being the buffer between integration, and platform engineering teams. I've been the person in the role as the evangelist when there is a bug in an API, and I'm at the mercy of an already overloaded engineering team, and QA staff, before anything gets resolved--this is a difficult position to be in.

How wide this chasm becomes ultimately depends on how much of a priority the API is for an engineering team, and how overloaded they are. I've worked on projects where this chasm is pretty wide, taking days, even weeks to get bugs fixed. I'm guessing this is something a more DevOps focused approach to the API life cycle might help with, where an API developer relations and support team have more access to making changes and fixing bugs--something that has to be pretty difficult to deal with at Google scale.

Anyways, I thought the potential chasm between developer relations and support was worthy enough to discuss and include in my research. It is something we all should be considering no matter how big or small our operations are. There is no quicker way to kill the morale of your API developer relations and support teams by allowing a canyon like this to persist. What challenges have you experienced when it comes to getting support from your API provider? Or inversely, what challenges have you faced supporting your APIs or executing on your developer outreach strategy? I'm curious if other folks are feeling this same pain.

All The Right Channel Icons In Support Of Your API Platform

I look at a lot of websites for companies who are providing APIs and selling services to the API space. When I find a new company, I can spend upwards of 10 minutes looking for all the relevant information I need to connect. Elements like where their Twitter and Github accounts are. These are all the key channels I am looking for so that I can better understand what a company does and stay in tune with any activity, but they are also the same channels that developers will be looking for so that they can stay in tune a platform as well.

I spend a great deal of time looking for these channels, so I'm always happy when I find companies who provide a near complete set of icons for all the channels that matter. Restlet, the API design, deployment, management,and testing platform has a nice example of this in action, providing the following channels:

  • Facebook
  • Twitter
  • Google+
  • LinkedIn
  • Vimeo
  • Slideshare
  • Github
  • Stack Overflow
  • Email

All of these channels are available as orderly icons in the footer of their site. Making my job easier, and I'm sure making it easier for other would be API developers. They also provide an email newsletter signup along with the set of icons. While this provides me with a nice set of channels to tune into, more than I usually find, I would still like to have a blog and atom feed icons, as well as maybe an AngelList or Crunchbase, so that i can peak behind the business curtain a little.

I know. I know. I am demanding, and never happy. I am just trying to provide an easy checklist for companies looking to do interesting things APIs of the common channels they should consider offering. You should only offer up channels that you can keep active, but I recommend that you think about offering up as many of these as you possibly can manage. No matter which ones you choose, make sure you organize them all together, in the header and footer of your website, so nobody has to go looking for them.

Every Government Agency Should Have An FAQ API Like The DOL

I wrote about my feelings that all government agencies should have a forms API like the Department of Labor (DOL), and I wanted to separately showcase their FAQ API, and say same thing--ALL government agencies should have a frequently asked question (FAQ) API. Think about the websites and mobile applications that would benefit from ALL government agencies at the federal, state, and local level having frequently asked questions available in this way--it would be huge. 

In a perfect world, like any good API provider, government agencies should also use their FAQ API to run their website(s), mobile, and internal systems--this way the results are always fresh, up to date, and answering the relevant questions (hopefully). I get folks in government questioning the opening up of sensitive information via APIs, but making FAQs available in a machine readable way, via the web, just makes sense in a digital world.

Like the forms API, I will be looking across other government agencies for any FAQ APIs. I will be crafting an OpenAPI Spec for the DOL FAQ API (man that is a lot of acronyms). I will take any other FAQ APIs that I find and consider any additional parameters, and definitions I might want to include in a common FAQ API definition for government agencies. This is another area that should have not just a common open API and underlying schemas defined, but also a wealth of server and client side code--so any government agency can immediately put it to work in any environment.

The Month At A Glance, Road Map, Support, And The Recent Posts For Your API Platform

I was playing with Microsoft's API Catalog, a tool to visualize and analyze the API overlap between standards specifications and type systems within browsers, and their footer caught my eye. I am always looking for quality examples of companies doing platform communications and support well, and I think their layout, and available building blocks in their footer, is worthy of showcasing.

For me, these numbers, and the available communication and support building blocks, send the right signals--that a platform is alive and active. These are the data points I tune into, to understand how well a platform is doing, or not doing. There are no absolutes when it comes to this type of monitoring, as anything can be gamed, but sign Github activity, road map evolution, and blog storytelling can provide a vital heartbeat for any healthy API platform. 

Managing The Support, Feedback, And Roadmap Using Github

Each of the Adopta.Agency project runs as a Github repository, with the main project site running using Github Pages. There are many reasons I do this, but one of the primary ones is that it provides me with most of what I need to provide support for the project.

Jekyll running on Github pages gives me the ability to have a blog, and manage the pages for the project, which is central to support. Next I use Github Issues for everything else. If anyone needs to ask a question, make a contribution, or report a bug, they can do so using Github Issues for the repository

I even drive the project road map, and change log using Github Issues. If I tag something as roadmap, it shows up on the road map, and if I tag something as changelog, and it is a closed issue, it will show up on the change log--this is the feedback loop that will help me move the clinical trials API forward.

Breaking Out API Support Into A Separate Research Area

Supporting your community is not unique to the API space, but supporting API operations does have some unique needs, and approaches that are proven by leading platforms. Like other areas of my research, I'm pulling out API support into its own area, so I can start shining a light on successful patterns I find in the area of API support.

Two things pushed me to spin out this research area. One, I was tagging more blog posts, and other resources as support, and without a dedicated research area, this information would rarely float to the surface for me. Two, my partners over at Cloud Elements have an API hub dedicated to "Help Desk". While their aggregate API solution is targeting beyond the API community, it is API driven, and can also be applied to providing an aggregate support solution for API communities.

As with most of the areas of the API space, there are several dimensions to how APIs are being applied to support customers, and online communities. With my research, I will focus on tracking on approaches to community support for API providers, and API service providers. There will also be that layer of tracking on help desk and support platforms who employ APIs, as well as API aggregate and API interoperability solutions from leaders (and my partners) in the space like Cloud Elements.

You can visit my API support research via its Github repository, and I will try to make sure and continue linking to it from my API management research, where it was born out of.

Update 265 Pages, and 175 Links On My Network To Support Swagger to OADF Shift

I have written 265 separate posts, across the API Evangelist network about Swagger, in the last three years. To reflect the recent shift of Swagger into the Open API Initiative (OAI), and the specification being reborn as Open API Definition Format (OADF), I wanted to update all the stories I've told over the years, to help educate my readers of the evolution, and provide the most relevant links possible.

Using my Linkrot API, which helps me manage the links across my network of sites, I've identified all the pages with Swagger relevant links, and made sure they are updated to point at the most recent material. I've also added a banner to each of the 265 posts, helping educate readers who come across these posts, regarding the transition from Swagger to OADF, and help them understand where to find the latest information.

My network of sites is meant to be my workbench for the API space, and provide the latest information possible about what drives the API sector. It is important to me that the information is as accurate as possible, and my readers stay in tune with the shifts of the APIs space, and where they can find what they need to be successful.

In the end though, all of this is really just business. 

Using Existing Online Forums vs Developing Your Own To Support API Operations

As I tune into the fallout around the Reddit community, I think it is a good time to pull a story out of my notebook, that I began writing a month or two ago. These thoughts are born out of my post Ask The Stack When You Need API Support, where my friend Jeremiah Lee (@JeremiahLee) commented, disagreeing with my recommendation that API providers use Stack Exchange as part of operations. 

Jeremiah shares his story about how hostile Stack Overflow can be (I'll let you read his comment on your own), something that has been re-enforced many times along the way. While I still endorse Stack Overflow as a valuable building block for some APIs, I completely agree with Jeremiah about the overall community tone. While Stack Overflow is definitely a different beast, it suffers from some of the similar systemic illnesses, that Reddit does. I find some very valuable information on Stack Overflow, which I use regularly, but if you are looking to develop an API community, I can envision the community potentially working against you, in several ways.

It really depends on your API, and the target audience you are trying to reach. Sometimes, the male dominated, "gamified community of meritocracy, where established members have many rules and politics", as Jermiah says, is exactly who you should be engaging, but you really need get to know the personae of your ideal customers, and decide on your own. For API Evangelist, both my storytelling, and the APIs I provide, I've long felt Stack Overflow is not my target audience.

Similar to Reddit, Hacker News, and DZone, I get very little value from these communities. While I do find nuggets of information at these places, I do not post my stories, and engage in conversations there, because the hostility that can come from these channels I have found outweighs any value they might bring in traffic. I seek a much wider audience, than the individuals who often dominate these tech hangouts.

I encourage you to think deeply about who you want to reach with your APIs, and while building your own community in your own wiki, forum, or other solution, might take a lot of time and work, it gives you greater control over the tone your forum takes--which might make the difference in attracting the right developer and business audience you seek.

@Broadcom, I Am Going To Need Your Switches To Support Virtualized Containers So I Can Deploy My Own APIs Too

While processing the news today over at API.Report, I came across a story about Broadcom delivering an API for managing their latest network infrastructure. The intersection of Software Defined Networking (SDN) and Application Programming Interface (API) is something I’m paying closer attention to lately. Hmmm. SDN + API = Brand New Bullshit Acronym? Meh. Onward, I just can’t slow down to care--{"packet keep moving"}.

At the networking level, I’m hearing Broadcom making a classic API infrastructure argument, "With the OpenNSL software platform, Broadcom is publishing APIs that map Broadcom's Software Development Kit (SDK) to an open north bound interface, enabling the integration of new applications and the ability to optimize switch hardware platforms.”, with examples of what you could build including "network monitoring, load balancing, service chaining, workload optimization and traffic engineering."

This new API driven approach to networking is available in the Broadcom Tomahawk and Trident II switches, looking to build up a developer community who can help deliver networking solutions, with Broadcom interested in giving, "users the freedom to control their technology, share their designs and boost application innovation.” Everything Broadcom is up to is in alignment with other valid Internet of Things (IoT) efforts I’m seeing across not just the networking arena, but almost any other physical object being connected to the Internet in 2015.

I think what Broadcom is doing, is very forward leaning effort, and providing native API support at the device level is definitely how you support “innovation” around your networking infrastructure. To keep in sync with the leading edge of the current API evolution as I'm seeing it, I would also recommend adding virtualized container support at the device level. As a developer I am thankful for the APIs that you are exposing, allowing me to develop custom solutions using your hardware, but I need you to take it one level further--I need to be able to deploy my own APIs using Docker, as well as working with your APIs, all running on your infrastructure.

I need your devices to support not just the web and mobile apps I will build around your around your hardware, and the API surface area you are providing with the new Tomahawk and Trident II switches, I need to also plugin my own microservice stack, and the microservices that vendors will be delivering to me. I need the next generation of switches to be API driven, but I also need to guarantee it is exactly the stack I need to achieve my networking objectives.

That concludes my intrusion into your road-map. I appreciate you even entertaining my ideas. I cannot share much more details on what I intend to do with your new SDN & API driven goodness, but if you work with me to let me innovate on your virtual and physical API stack—I feel that you will be surprised with what what the overall community around your hardware will deliver.

Ask The Stack When You Need API Support

I was profiling the video sharing API Dailymotion the other day, going through their developer area and profiling their API operations. One of the things I do as part of the profiling of any company, is checkout how they execute their support.

Dailymotion employs two very common building blocks for their platform support, including an API specific Twitter handle, and good ol fashion email—both pretty proven approaches. However Dailymotion also employs a third aspect to thier API support, by recommending you head over to Stack Overflow for some community support.

Using Stack Overflow in this way is not that original, I see numerous API providers doing this, the part I found interesting was their reference to getting Dailymotion API support via Stack Overflow as, "ask the stack!" I like that, I think it reflects what Stack Overflow is to the API developer community, and was an elegant way to send API developers off your site, to get the support they need.

APIMATIC Code-Generation-as-a-Service Has Built-In Support For API Commons Manifest

The API savvy folks over at Apimatic are at it again, pushing forward the conversation around generating of software development kits, using machine readable API formats, and this time the doorway to your SDK is via the API Commons manifest.

I'm going to go ahead and use their own description, as it sums it well, no augmentation needed. Using the code generation API, you can generate SDKs for your API directly from your Github repository. 

Step 1: Describe you API using some format. You may choose from Swagger, RAML, APIBlueprint, IODocs, and Google Discovery formats. Automatic code generation makes use of information in your API description to generate method and classes names. Please be as expressive as possible by not leaving out any optional fields as applicable e.g., not leaving out types and schemas for your parameters and fields.

Step 2: Define meta information about your API using API Commons manifest format. You can generate your API Commons manifest using the API Commons Manifest generator. Be sure to enter all relevant information. Upload the generated manifest as a new file in the root directory of your Github repo by the name "api-commons- manifest.json". Be sure to have the correct name and location of this file.

Step 3: Open/Create a markdown file ( is a good candidate). Add the following markdown syntax to render an image link.

[![apimatic][apimatic-{platform-name}-image]][apimatic-{platform- name}-url]

[apimatic-{platform-name}-url]:{account-name}/{repo-name}/{branch- name}?platform={platform-name}


Replace the {platform-name} token with one of the following values: windows, android, ios
Replace the {account-name} token with the name of your url-encoded Github account name
Replace the {repo-name} token with the name of your url-encoded Github repository name
Replace the {branch-name} token with the name of your url-encoded Github branch name where the API Commons manifest file is present. 

To validate, open the following url after replacing tokens. This url should open the raw manifest file.{account-name}/{repo-name}/{branch- name}/api-commons-manifest.json

You can see an example here. Commit changes and navigate to your Markdown file in your browser. You will see apimatic widgets (image links), which you can click to generate SDKs for your API. To see an example, open this link to view the file in raw text form.

The Apimatic team is owning the conversation when it comes to generation of full fledge SDKs for your APIs. I always hear folks talk about the limitations of auto-generation of client side code, but the Apimatic team is pushing the conversation forward with their persistent approach.

Why Would You Ever Give Students API Access To The Student Information System (SIS), And Let Them Build Un-Sanctioned Apps That We Will End Up Having To Support?

I went up to California State University Channel Islands the other day to talk APIs with their tech team, and I was happy to find at least one strong API skeptic on the team. API skeptics also give me material for stories, so I thoroughly enjoy coming across them, and telling these stories is how keep polishing my argument for the next API skeptic encounter at campus IT, at the higher educational institutions that I visit.

During the discussion I was posed several interesting questions, and one of them was: why would you ever give students API access to the Student Information System (SIS), and let them build un-sanctioned apps that we will end up have to support?

Family Educational Rights and Privacy Act (FERPA)
FERPA gives students the right to review, control disclosure, and request amendment of their education record. Increasingly this is going beyond just via a web interface, PDF, or printed copies. President Barack Obama mandated that all federal agencies begin providing information in machine readable formats, and many cities and states are putting it into law as well. A student should always have access to their data, and they should be able to choose to do this via campus applications, or be able to obtain a portable copy of their record for storage in a location of their choosing, or possible use within a 3rd party system of their choice—it's their data. Period.

Un-Sanctioned App Concern Is Just A Red Herring
Modern API management infrastructure like 3Scale, and WSO2, provide an unprecedented level of control over managing API access, requiring secure on-boarding of new developers, the establishment of service composition definitions, which provides rich real-time analytics on how APIs are used, and by whom—while also seamlessly integrating with existing identity and access management solutions. The university gets to choose who has access to which services, revoke access when abused, while also better understanding how resources are really being accessed and put to use. Ideally this applies to all campus-wide usage, as well as with external 3rd parties—modern approaches to API-centric operations, include the management of internal, partner, and public resources in this way.

A More Balanced Governance Across Campus Resources
Modern API management was born out of traditional IT governance, but is something that is more focused on giving access and control to the end-users who are the actual owners, of the valuable data, content, and other digital resources being made available. Legacy campus IT models provide a governance model that involves IT, administrative and faculty stakeholders, but rarely includes the students. APIs give students secure access to their data, and standards like oAuth opens up the ability for them to have a vote in who has access to their data, with oAuth scope being defined by existing institutional governance efforts. When APIs enter the conversation, governance expands to be more self-service, real-time, and within the control of students, as well as administrators, faculty, and campus IT.

Possibility Of Good Things Happening Closer To The Student
In the current educational environment, where students are often more tech savvy than faculty and administrators, why would we want to eliminate serendipity, and the possibility that new things might happen. Solutions to problems that students actually face everyday, that campus administrator may never think of, because they see technology through a very different lens. The days where IT knows best, regarding what devices, browsers, apps, and websites are optimal for getting things done, are in the past. Shadow IT demonstrates this, where students, and even faculty are using un-sanctioned solutions to get their work done. Campus IT should be empowering students, encouraging a more digitally literate individual who soon will be entering the workforce, not suffocating this.

Easy For Campus IT To Miss The Big Picture
I am a recovering IT administrator, so I understand the challenges a skeptic campus IT administrator faces, but ultimately by restricting access to campus resources just makes your job harder, making you the bottleneck that everyone's so commonly complains about, when it comes to IT. APIs don’t create more work for you, it makes you much more agile and nimble in how you integrate systems, build new web and mobile applications, and provide 3rd party vendors access to campus resources—as well as potentially opening up self-service access to students.

With an API-centric approach you will know exactly who is accessing resources, and how they are using them--in real-time. I’m betting that you don’t have this visibility across all of your IT resources right now. When I put on my IT director hat, I prefer the API model, because then all resources are self-service, available to only those who SHOULD have access, all without them having to talk to me. I’m left alone to do what I do best, and can also monitor new signups, real-time usage, and manage support tickets in accordance with wider IT support strategies.

I understand you are a skeptic about APIs being a thing students should have access to, and in reality most students will not care, but there will be a long tail of student users who will do things you never imagined, and potentially change how you look at scheduling, document management, or other staples of campus operations—something that will never happen if you don’t make students a priority when it comes to your digital resource management.

Disclosure: 3Scale and WSO2 are both API Evangelist partners.

Developer Support With Google Helpouts

I was cruising around the Google Developer area and I stumbled across Google Helpouts. A service being billed as “Experts with Answers, Meet Developers with Questions”. Seems like a more one-to-one version of Stack Overflow, where you can get the answers you are looking for when it comes to development on the Google platform, but in a more direct, one-to-one way.

Inversely, you can contribute your developer skills, and be one of the knowledgeable developers who are giving back to the developer community. The Google Helpouts page describes it as: Give Back - Continue Learning - Build Your Reputation. I signed up for an account, gave my profile, but the tags that I was able to connect with my profile really didn’t match my skills. It seems very programming language, and platform focused at this point--not really for APIs.

At first glance I thought Google Helpouts was more about Google APIs, available as an exentsion of the Google Developer program, but it seems to be a more tech focused, skills matching service. I think the same concept would work well, if applied to APIs, but I don’t see any reason for a new platform, just build it on top of Stack Overflow API—why re-invent the wheel?

Sales, Onboarding And Support In A Self-Service API World

I was reviewing an API over the last couple of weeks--I signed up for an account, came back several times, and made a handful of API calls in hopes of learning more about how the API works. This is something I do a lot, and it is always interesting to experience the on boarding process (or lack of) for APIs.

I first signed up about two weeks ago for this particular API, and within 48 hours I received an email asking if I needed help with my integration--that was nice of them. I like getting an email from the provider, and the more human it is, the better. At this point I didn't need any help, I’m just playing, learning, and depending on the self-service resources made available to me via the API ecosystem.

About a week later I get another email, again asking if I need help. At this point I’ve put down the API, but when I pick back up I might respond to the platform then, but I just have more learning to do before I have questions. Then about a week later, right before I was about to pick up the API again, I got another email asking me what my plans were, putting more pressure on me to share my plans for how I was going to be using an API, which I'm just not sure yet.

I am not your usual API consumer. I know this. However this API, I was actually planning on integrating into my core API tracking system at some point, so in addition to being the API Evangelist who might write a story, there is a good chance I will become a customer. I really like, and believe in the self-service nature of APIs, and while I like getting an email letting me know someone is home, I tend to be turned off by each consecutive email--nothing reminds you are in someones sales funnel, like a series of emails.

When you consider the touch points for your API on-boarding flow, make sure and think about the different types of users who will be registering, and the fact that not everyone will fit squarely in your perfect funnel definition. You want to make sure your API consumers know that someone home, and that you are there to help, but you really should rely on your self-service resources to get the bigger job done. Your initial email after I sign up should do this, then leave the next steps up to me, and be very thoughtful, and possibly dynamic with each engagement after that.

My Continued Support As Signer Of Oracle v Google Amicus Brief From EFF

As the Oracle v Google API copyright case was on its way to the Federal Circuit Court in 2012, the EFF reached out to me for help in crafting stories of how important it is that APIs remain free of copyright, ensuring they remain open and interoperable. I shared three stories, one on cloud computing and AWS APIs, the second on Delicious APIs, and the third on Instagram APIs, all reflecting three different scenarios that would never have happened if APIs were copyrightable.

A couple weeks ago EFF reached out again, asking for my signature again, on another Amicus Brief to support Google’s request of the Supreme Court to review the circuit courts decision, and reverse it. As it stands right now, there is a precedent that copyright can be applied to APIs, and even though the case itself is moving onto the question of fair use, if we let the current decision stand, other companies can follow Oracle’s damaging lead and sue for protection of their APIs--which is why we need to convince the Supreme Court to review, and overturn the very damaging decision. 

We expect that the Supreme Court will decide whether or not to grant Google’s petition to review the Federal Circuit’s decision sometime in January or February of 2015. So I need your help to stir up buzz around the issue, and post stories on your blog, call your congressman, and light up any other channel you can, to help educate people about the importance of the issue. When the Supreme Court takes on the case (which I feel strongly they will), we will need to regroup, and refile, a more expansive brief on the importance of APIs remaining free of copyright. 

I’m working to expand my restaurant menu analogy, to help people understand the importance of APIs, but if you have other analogies that you think would help the Supreme Court understand the separation of API interfaces, and their supporting server side or client side code, please share with me so I can work with the EFF to potentially include in the next brief that is filed. APIs are touching every sector of business in 2014, and if we allow Oracle’s copyright claim to stand, we are in danger of pouring glue into the gears of each of these business sectors, at a point in time where we need to introduce as much lubrication, and transparency as we possible can, to ensure that the web, mobile, and Internet of Things applications built on APIs remain open and interoperable--ensuring they serve not just their platform owners, but also developers, and end-users equally.

Join me, in helping bring awareness to the issue, which right along with Net Neutrality, is one of the most important issues we currently face when it comes to deciding the future of technology, and how our society works, shares, collaborates and interoperates in this new online digital world we have created for our world.

Wunderlist adds Dropbox support to help you better manage your to-dos

The mobile and desktop to-do list app Wunderlist has added Dropbox support, allowing users to automatically attach files stored in the cloud directly to tasks. The company said the move is the first of many integrations of third-party productivity tools and that Dropbox support in particular was one of the most requested features. To get started with it, all you need to do is click on the Dropbox item in detail view and select the file you want to add. If you then change that file in some way, those changes will automatically sync back to the file attached to Wunderlist, negating any need to reattach it. A spokesperson for the company confirmed that the new feature is avaialable on Wunderlist for the Web and Android from today and that it should land for iOS devices just as soon as Apple approves the updated app in the “next few days”.


Explaining My Work Around APIs In Higher Education To Institutions

I’m needing to quantify the work i do around APIs in higher education for a university in the U.K., so I figured I’d craft into a story that I can share with my readers, and potentially other schools who would ask what it is that I do.

I am interested in APIs in higher education because I feel strongly that our institutions are a fertile environment for ensuring that the next generation of our society possess the digital literacy they will need to navigate and find success in our increasingly digital world.

When I mention that higher education institutions should be incorporating APIs into daily operations, most folks immediately think of a very technical, IT directed effort, which is one layer to the discussion that should be considered, but ultimately it is about developing an awareness, and engagement by administration, faculty, and the students with the increasingly public APIs that surround us, as well as internal institutional APIs.

Our personal, and business lives are moving into the cloud. We are increasingly dependent on web-based and mobile applications in many aspects of our lives, and a growing number of these software services have APIs, and API-enabled actions that can be taken by anyone, even non-developers.

My mission as the API Evangelist is to help everyone be aware that APIs exist, and that they are there to assist you in your personal and business life. Which brings me back to higher education institutions being an important place to expose students, and faculty to the benefits of APIs—in preparation for the increasingly API driven world unfolding around us.

While I pay attention to over a 100 categories of APIs, let’s take one area, photos and images, and use as a backdrop for what I do. I pay attention to over 25 photo and image APIs that provide image related services for developers, as well as direct access to the popular photo and image platforms we often depend on like Flickr and Instagram.

As the API Evangelist I seek to pay attention to three key layers of the API space.

Technology of APIs - The geeky detail of how APIs work.

  • How do I authenticate?
  • Where do I read data from?
  • How do I write data?
  • Where are their code samples in my language?
  • Where is the WordPress plugin?

Business of APIs - The business profile behind any online service.

  • How much does the service cost?
  • What are the limitations of what I can read or write?
  • What kind of support is available to me?
  • What are the long term plans of company?
  • Is the platform and tools well documented?

Politics of APIs - The often complex politics behind the curtain.

  • Do I own my data? Do I own my photos?
  • Can I specify the license for my photos?
  • What are the security practices?
  • Do I have control over who access my data (aka oAuth)?
  • Are code libraries, tools, and other code open sourced?
  • Are the terms of service easy to understand? Fair?

APIs are much more than just technology and when you compare platforms like Flickr and Instagram which both act as photo sharing platforms, but have widely different approaches to the technology, business, and politics of each of their APIs. Sometimes it is just small details that can make the difference in whether or not a platform is the right choice or not for any individual or business.

Beyond the technology, business, and politics I also pay attention to a handful of important trends that are growing out of the API space, to support API consumers.

Realtime - What options are there to interact in realtime.

  • How do I send / receive push notifications?
  • How do I use webhooks to receive updates?
  • Does this API have a streaming API?
  • What frameworks are available for real-time delivery?

Aggregation - Details on API data and information aggregation.

  • Can I get all of my images from Flickr, Instagram in a single feed?
  • Can I publish to one place, and have it syndicate out?
  • What options do I have for POSSE (Publish (on your) Own Site, Syndicate Elsewhere)

Reciprocity - Approaches to moving data from one system to another.

  • Can I migrate all of my flickr images to dropbox?
  • Can I keep all of my flick, instagram, and other photo sites in sync?
  • Where is the best place to store my photos?
  • Can I transform images when moving from location to location?

I’m not just about watching, and monitoring what is going on in the API space, my mission demands that I take what I learn and produce content that everyone else can benefit from. To fulfill this, I take all of my curation, analysis and awareness, and I work to create rich content that is designed for the widest distribution possible:

  • Short Form - Blog posts on my primary blogs (,,,,, and kin
  • Long Form - White papers and ebooks that get published either public, or in some cases privately for internal organizational distribution.
  • Presentations - Walkthroughs, talk presentations, and other interactive content that introduce people to the world of APIs.
  • Videos - Generating video content, around my research and presentations for publishing to YouTube and other video distribution sites.

I strongly feel that it isn’t enough that I'm doing all of this work online, I’m also invested in stimulating in-person conversations in the following formats:

  • Conversations - In person, small group conversations with team members about APIs.
  • Classrooms - Teaching large, or small classrooms at institutions around the world.
  • Meetups - Supporting the creation of, and guest speaking of API focused meetup groups around the world.
  • Conferences - I support up to 10 API conferences, while also putting on my global conference on APIs called @APIStrat

API evangelism for me is not just about educating developers that APIs exist, it is about bringing awareness to the masses that APIs exist, and they are just the next evolutionary layer of the web that has penetrated almost all aspects of our lives. I focus on bringing an awareness of APIs to:

  • Individuals - Every citizen. API literacy is like financial literacy, you don’t need to understand the entire banking system, but you will need some basic financial literacy to manage your bank account, and credit cards—the same applies in the API space, you don’t need to understand everything about oAuth, but you should know who has access to your bank account, Facebook, and YouTube accounts.
  • Business - More business activity is occurring online, and APIs are rapidly making business data and information available to the average business user for use in spreadsheets, mobile and web applications. Basic API literacy is fast becoming a requirement for many business sectors.
  • Institutions - Over the last 15 years, many institutions have moved online, establishing a web presence, and connecting with partners, and constituents via the web. Large organizations need to understand how to use APIs to become more resilient, agile, and nimble in an age where much is changing when it comes to how the institutions of yesterday are perceived and stay relevant in the future.
  • Government - Our government is required to do more with less, and APIs are the way we are slowly shifting government of all sizes, operate and engage constituents. Federal, state, and local governments are opening up data, making resources available via APis, and shifting the burden of governance to private sector partners, and even the public using APIs.

Helping everyone understand the API undercurrents that are occurring right now all around us, is my mission as the API Evangelist. Everyone needs to understand that APIs exist, and have a basic understanding of how they can put them to use in their personal and business world. This isn’t some grand, techno vision being sold from Silicon Valley that I'm looking to sell to universities, this is about what is already happening around us on the web, via our personal mobile devices, our homes, businesses, cars, and much much more. API Evangelist is about helping regular folks see what is happening, understand as much of it sa they can, allowing them to take meaningful action with the context of their lives.

Continuing to bring this higher education API venn diagram tighter, is additional work I’m doing with in two very quiet, but extremely important initiatives.

  • Domain of One’s Own - A program occurring at a handful of higher education institutions, where students get their own domain upon entering school, which can be used for their projects throughout their academic career, and even beyond if they choose—giving each student the gift of web literacy.
  • Reclaim Your Domain - A secondary project spun out of Domain of One’s Own which is about providing education materials, tools, and other resources for students, and any other individual to map out their online domain, and put together a strategy for reclaiming parts of their digital identity.

To do my work I use my own custom developed internal system, where I aggregate information about over 2500 APIs, 1500 RSS feeds, 2500 Twitter accounts, and 750 Github accounts. From there, all of my short form and long form content, as well as presentations, and other supporting research gets published to 75 individual open source research projects managed using Github. My intent is to make sure all of my research, and resulting data is publicly available in open formats, allowing anyone to fork, extend, and expand on what I do.

How can my research help your institution better understand, internalize, and apply APIs?

You can visit my research on APIs in higher education here:

Here are some other recent stories I've published recently in the area of APIs and education:

The API Focused Dev Shop

I tag a lot of interesting companies that show up during my weekly API monitoring. When I see a tag go from 1 or 2, to over 5 companies--I take a closer look to see what is going on. An increase in the number of companies focusing in a specific area could be a trend, or it could be nothing.

The tag "API Agency" ticked over to 6 today, when I added Aquevix, an indian company that is focusing on API development. As of August 2014 I now have six separate agency style companies that I've found who have a focus on API design and development:

6 Companies
API Support

Developer Support Beyond FAQ, Forums and Documentation. First class support for your API. Processing an API request often means directly or indirectly interacting with 2 or more systems. Is your support team equipped with the necessary training, tools, information and support infrastructure to be successful? IT Assist helps you design and implement your API support strategy and infrastructure, offer training to your support team and as needed handle your developer support.


We are a small Independent software business specialising in the. Enhancement of existing software. We use standalone applications and APIs to extend the functionality of existing systems. Integration of separate systems. We connect disparate online SaaS applications together to create an integrated system. Automation of business processes. We convert manual menial tasks into automated business processes, reclaiming time and costs.


We design market strategies for companies looking to extend their APIs into digital partnerships. API Strategies to accelerate social and mobile content and digital partnerships. Big data asset definitions and valuations to define API approaches. API pricing and tier strategies to monetize data. Developer and partner outreach strategies to expand mobile success and "mash-ups”. Business model development for emerging start ups and matching them to enterprise clients and needs. Best practices to compete and win in the social, mobile, and big data marketplaces.


Aquevix is the go to company that can weave the abstract into a finished product. We are a software company that provides innovative, business solutions worldwide. Need an API? We got you covered. We provide full REST/JSON based API implementation and related apps with best practices! We are capable of developing highly specialized APIs that integrate seamlessly with powerful apps and increase overall performance of applications.

Blue Jazz Consulting

Blue Jazz Consulting is focused on guiding product companies from idea to revenue using Ruby and Rails and Java-based technologies. Based in Austin,TX, we bring experienced professionals and a history of successful projects to the community. We offer expert consulting services for existing products and early-stage startups. We offer expert consulting and development in software architecture, specifically on the backend requirements of complex B2C and B2B applications. We love to model, design, and build web and mobile APIs to ensure that your business capabilities can be consumed successfully by internal developers, devices, and third-parties using a Ruby or Java platform.


At Stateless we employ our specialist experience, design processes and tools to ensure our clients realise the most value from their APIs. We're making the world of APIs beautiful.We work with you to surface the business goals for the API. We decide on the metrics to measure and track. These will help in understanding whether we are achieving our goals. We create developer personas to represent the various types of consumer, and a roadmap to deliver features tailored to them. We offer engineering and product management resources delivered using the best modern processes and tools. We employ Lean practice by tracking important metrics and constantly feeding that insight back into the live roadmap. We provide technical writers, and use the latest tools and techniques to interlace your test suite and your documentation.

We'll see how many more dev shops I find in the next couple months. Sometimes when I start focusing in a new area I will find more companies working in the same area, purely because I'm looking harder, and sometimes it takes time for things to actually heat up.

As I'm looking at local Chicago web and mobile development shops during the lead up to API Strategy & Practce in Chicago next month, and I'm learning that many small shops like SYDCON and Blaze Portfolio are using APIs, they just havn't shifted their marketing and web site content to reflect the evolution.

It won't take much for many of these web and mobile development shops to standardize their API design and development services, much like the evolution we saw occur from web to mobile development, shifting the focus of the small dev shop to better serve a growing demand for API design, and development. I think by 2015 I'll see over 50 development shops, who are heavily focused on API design and developmennt in my API tracking system.

P.S. I REALLY like the API Chappies, and Mike @ Stateless is the freak'n man!

Where The Good IPAs Are In Chicago While At API Strategy And Practice In September

In preparation for API Strategy & Practice in Chicago, September 24-26th, I did a little research on where the good beers, and specifically the kick-ass IPAs can be found. You may not know, but in addition to being the API Evangelist, I am also the IPA Evangelist (plan b career path), and I'm always interested in knowing where the killer IPAs are, in addition to knowing where to find the best APIs. 

While in Chicago we want to be able to have the tasiest beer possible at the conference, while also having the best options for finding good beer and food after the event to network and socialize with the 600+ folks that will be at #APIStrat. To prepare for #APIStrat I found 32 local Chicago breweries:

5 Rabbit Cerveceria

The first Latin microbrewery in the US, 5 Rabbit is all about making the best beer.

Ale Syndicate

At Ale Syndicate, we are dedicated to making craft beer worthy of Chicagoans. Please drink responsibly! ALE SYNDICATE BREWERS, CHICAGO, IL BEER.

Argus Brewery

The Chicago beer you SHOULD be drinking. Our Chicago Attitude is something of which we're proud. Something we think you'll taste in each Argus Brew-flavor, depth, the unusual and carefully brewed taste of a premium craft beer..

Atlas Brewing Co.

Atlas is a brewery and restaurant committed to providing Chicago with fresh, delicious beer and food to match. And we have a bowling alley attached....


First bred in 1989, Baderbräu is back and here to stay. The return of Chicago's original craft brew. We also hope that you'll try our future offerings, with equally high expectations, and become fans of those to.

Begyle Brewing

a Community Supported Brewing Company! Visit us at our brewery store for growlers and packaged beer to go! 1800 W. Cuyler, Chicago, IL 60613.

Berghoff Beers

Berghoff’s history goes back over 120 years and, in that time, has developed a reputation of high quality and consistency that you’d expect from a hard-working men and women dedicated to their craft..

Big Shoulders Beer

Big Shoulders has taken the time to find the right connections and people to be committed to bringing you great beer..

Cahoots Brewing

Cahoots Brewing is a new brewery in Chicago. Our first beer, No S'more Imperial Stout, is out now. Our goal is to build beers together..

Chicago Beer Company

It's Chi-Time! Chicago Beer Company Craft Beers are available in IL.IN.MI. Wheat Rated 90pts GM; Lake Shore Lager 91pts GM & Pale Ale 88pts SM.

Dryhop Brewers

A brewery and kitchen in East Lakeview, Chicago. Tweets by @gregshuff @brantdubovick & @ecgarrity Cheers..

Finch's Beer Company

Finch's Beer Co. is in the business of brewing great, craft beers locally in Chicago, IL..

Forbidden Root

At Forbidden Root, we craft delicious botanical beverages for today's sophisticated thrill-seeking palates..

Goose Island Beer Co

Since 1988 Goose Island has innovated what beer can be. Follow us to see What's Next. Cheers from Chicago..

Half Acre Beer

We brew many beers throughout the year. Our focus is brewing raw & basic ales & lagers rich in material and undisturbed by process..

Hamburger Mary's

Hamburger Mary's is an open-air bar & grille for open-minded people.... That brews it's OWN BEER! Yumm :-).

Haymarket Brewing

Haymarket Pub & Brewery opened in December 2010, and features classic Belgian and contemporary American beer styles from brewing legend Pete Crowley..

Hopothesis Beer Co.

We’re relentlessly focused on making great craft beer that delivers a flavorful, approachable, balanced drinking experience for geeks and non-geeks alike..

Lake Effect Brewing 

Our name refers to the weather phenomenon most famous for its legendary snow storms. More importantly, the lakes create their own climates where the water temperature promotes an ideal environment for growing barley, wheat, fruits, and hops..

Local Option

The Local Option offers over 30 unique and rare beers from around the world on tap (with many more in bottles), intense Creole food, and a lively atmosphere indicative of the robust beer we proudly serve..

Metropolitan Brewing

Each year, we brew one 30-barrel (that's sixty half barrel kegs) fermentation vessel of Zwickelbier, meant to be enjoyed raw, cloudy, and as fresh as humanly possible. We package it, ship it, and bars across Chicagoland put it on tap pretty much the minute they receive it..

Moody Tongue Brewery

At Moody Tongue, our goal is to create thoughtful, exciting beers that blend familiar flavors and quality ingredients..

Moonshine Chicago

Moonshine is an edgy, urban roadhouse conveniently located in Chicago’s fashionable Wicker Park neighborhood..

Off Color Brewing

We make beer. Sometimes we do other stuff but not as well.


Brewing award-winning beer and serving delicious New Haven style pizza. Sports, live music, and Live band karaoke every Sat @ 11PM..

Pipeworks Brewing Co

Pipeworks Brewing Co. is a Chicago Brewery with a focus on creative small batch beers, brewed with expertise, passion and rock n roll..

Revolution Brewing

Revolution Brewing is Chicago's new hometown craft brewery. Brewpub in Logan Square & Brewery in Avondale..

Rock Bottom Brewery

Passionate about pints. Maniacal for malts. Rock Bottom is always brewing.

SlapShot Brewing

Brewing small batch hand crafted ales in Chicago, with a focus on session beers..

Spiteful Brewing

Chicago nanobrewery located in North Center. Fine beer brewed with spite..

Une Année

A Chicago Brewery focused on making great beer with an emphasis on Belgian and French styles. .

Veteran Beer Company

A company that brews superior quality beer while striving to employ veterans in every role in the organization..

If you know of a brewery that is worthy, and is not listed, add it to the comments below. If one of the breweries listed is kick-ass, please also let us know so we can prioritize the location as part of planning.

After looking through all these killer beers, I'm even more pumped for #APIStrat now. See you in Chicago!!

If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.