Over a million developers have joined DZone.

Addressing the API Consumption Side: 5 Predictions for 2016 & Beyond

Providing pre-built external integrations are a competitive imperative for SaaS companies and application providers.

· Integration Zone

The Integration Zone is brought to you in partnership with Cloud Elements.  What’s below the surface of an API integration? Download The Definitive Guide to API Integrations to start building an API strategy.

From an API Consumption perspective, 2016 will be a year of change. I’m predicting more API integrations will be built by Citizen Integrators (the average business user like a marketing admin or sales ops person), than by developers.  Providing pre-built external integrations are a competitive imperative for SaaS companies and application providers. APIs will finally embrace customization and API event management will be more than just an afterthought.

1. More API Integrations Will be Done by Citizen Integrators than Developers

avg-business-user.pngIntegration has become a leading use case driving the consumption of APIs, and will likely surpass the traditional application development use case of using APIs to enhance an application's functionality. Traditionally API integration has been the domain of software developers and IT organizations. However, we are seeing a strong shift toward self-service and pre-built integrations that provide application administrators and application users with the ability to connect SaaS apps together in order to share and synchronize data among the apps they use to run their departments.

These “citizen Integrators” are not developers, their not IT personnel but they have an understanding or their data, have specific use cases to ensure they don’t duplicate data and expect applications to work together. We like to call them the Average Business User.  By 2018, more than 50% of the cost to implementing 90% of the new large systems will be spent on integration - Gartner, 2015 AADI Postmodern ERP Integration Session. 

In fact, Gartner estimates that by the end of 2016 there will be more budget spent on integration outside of IT. Tools like Zapier, IFTTT, and Adeptia provide a self-service experience for citizen integrators to accomplish basic integration use cases. The leading application providers like HubSpot, Zendesk and Namely provide pre-built, packaged integrations that can be configured by application administrators.

2. Pre-built External Integrations Will Become a Competitive Imperative 

Based on the rise of Citizen Integrators, as mentioned above, we see SaaS companies and application providers assuming responsibility for much more of the integration responsibility. Until recently application buyers were expected to buy apps that didn’t necessarily work together and then wait for IT departments to purchase and implement expensive tools such as ESBs or iPaaS platforms to make them work together.  Or hire expensive system integrators to make the disparate systems work together.

However, with the proliferation of SaaS applications and the expanding range of options available in each category buyers are now becoming more insistent that the applications they buy work, out-of-the-box, with the applications they already have, or they won’t buy the new app.

This expectation from buyers has led application providers to focus on offering more pre-built integrations along with their apps. We see this as shifting from a nice-to-have to a top strategic imperative for application providers to compete and dominate in their markets. One example that comes to mind is our customer, Influitive.

The Director of Product Management at Influitive leads the team responsible for native integrations and has deep empathy for the marketers who are being challenged to figure out how to make it work in their ecosystem of other CRMs and automation systems. His mission: take the burden off the marketer’s shoulders to make it “work” on their own and deliver beautifully seamless integrations that they can rely on. And that’s where Cloud Elements comes in.

We see more firms not only providing pre-built connectors but embedded integration tools such as data mapping, bulk data migration, and even workflow and orchestration capabilities from within their apps.

3. APIs will Finally Embrace Customization

Every leading SaaS application offers its application users the ability to easily create, update and delete custom data fields and custom data objects. This flexibility has led to a vast majority of app users relying on custom data within their applications as they tailor the data they capture to their business needs.

However, very few SaaS applications provide custom object management within their APIs. Salesforce is a leader in this area with the ability to discover custom data fields, objects and their metadata, and the ability to create, update and delete custom objects programmatically through APIs. As integration use cases become the primary means of consuming APIs we expect more and more application providers to enhance the support for custom fields and objects within their APIs.  

To support these new modes of consumption it is imperative that API publishers recognize the need for their APIs to embrace the discovery and CRUD management of custom objects.

4. Event Management Through APIs Becomes More Than An Afterthought

The purpose of API integration use cases is to move and synchronize data between endpoints. Business Process Management is now occurring by assembling APIs into orchestrated workflows that synchronize and coordinate activities among multiple endpoints. To accomplish these synchronization and workflow use cases, requires the programmatic consumption of create, update and delete events from the endpoints through APIs.

aaarr-webhooks-pirate.gifWebhooks provide the most efficient means for publishing events from an endpoint as it does not require the consuming application or service to periodically poll the endpoint for changes. Polling increases traffic and often impacts limiters set up by endpoints by increasing activity. By subscribing to webhooks your application is notified only when a change is made thereby reducing traffic.

Currently a very small percentage of endpoints support webhooks. Of the 100+ integrations we’ve completed, we estimate that only about 10% support webhooks and even fewer endpoints support the programmatic configuration of webhooks through APIs. Even endpoints that support webhooks often only provide support for a limited set of resources.

Based on discussions with API publishers we see more sophisticated event management and webhook support as a high priority roadmap improvement as opposed to an afterthought as more publishers embrace the needs of the rapidly growing integration use cases.

5. Machine-Readable API Docs Will Go Mainstream

Machine-Readable API Docs is the advent of Swagger 2.0 and RAML. Both of these API Documentation creators enable applications to ingest a model of an API (e.g., JSON Model Schema) and then integrate and maintain the APIs while minimizing coding.

The ability to electronically discover API models and identify changes to these models will facilitate more reliable and easier to maintain consumption of APIs. To learn more about Swagger 2.0 I highly suggest you check out a few blogs by our partner, the API Evangelist, Kin Lane:

There is also a nice overview of the machine readable API documentation tools provided by RAML.

The Integration Zone is brought to you in partnership with Cloud Elements.  Are your customers demanding integrations? Learn the steps to designing API integrations and connecting SaaS apps in the 10 Step Guide to API Integrations.


Published at DZone with permission of Mark Geene, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}