State of API Integration 2018 Report

Loading ...
Techceler...
Technology & Engineering
Integration
<p>2018 State of API Integration Report
1
2018 State of API Integration Report
2
Table of contents
     A Word from our CEO  ...........................................................................................................  03
     Meet our Contributors  ..........................................................................................................  04
Section 01: Introduction  ...................................................................................................  05
     Behind the Data ....................................................................................................................  11
     The 2018 State of API Integration Survey Respondents  ............................................................  12
Section 02: Trends in API Integration .............................................................................  13
    Building a Platform Strategy ....................................................................................................  15
    Drivers of Adoption ................................................................................................................  19 
    Customized APIs  ...................................................................................................................  20
    Strategic Shift of Integration  ...................................................................................................  23 
    Evolution of B2B Integration ...................................................................................................  25
    Flexibilty ................................................................................................................................   26
    Longevity  ..............................................................................................................................   27
Section 03: Developer API Integration  ..........................................................................  29
   Emerging API Styles  ................................................................................................................    35
   API Security  ............................................................................................................................   39
Interactive Calculator  ........................................................................................................  44
Closing  ....................................................................................................................................45
    
2018 State of API Integration Report
3
A word from our CEO
Our Mission is to Integrate App 
Ecosystems by Unifying the World's APIs. 
Integration. It's that pesky part of making a product that no 
company actually wants to do. (And who can blame them? It's not 
easy.) But it's also the part that really has to be done well. Because 
if your product can't be used by the people who need it, then why 
build it in the first place?
It goes far beyond a simple connection to an API. Cloud Elements 
has re-imagined the world of application integration so you and 
your customers can focus on the data they care about. 
This report addresses the continued growth in API adoption, where 
the market is headed with ease of integration, and new trends in 
the coming year.
Happy Integrating.
Mark Geene
CEO - Cloud Elements
@mgeene
2018 State of API Integration Report
4
Meet our Contributors
Ross Garrett
at Cloud Elements
@gssor
Ross Garrett is the VP of Marketing at Cloud Elements - responsible for 
market strategy, product positioning and evangelism. He is a well-known 
speaker at developer events and other industry conferences. 
Kin Lane
at API Evangelist
@kinlane
I am the API Evangelist. Not in the sense that I'm evangelizing a single 
API to you--In the sense that APIs are important for everyone to be 
aware of. I'm paying attention to not just the technical, but the business 
and politics of the web API movement. 
Isabelle Mauny
co-founder and CTO of 42Crunch
@isamauny
Isabelle Mauny, co-founder and CTO of 42Crunch spent most of her 
career at IBM, across a variety of technical roles, at the European level. 
She was part of the IBM WebSphere Strategy board and played a key role 
in the deployment in Europe of flagship products such as the WebSphere 
Application Server or DataPower appliances. 
Mark Boyd
API industry analyst
@mgboydcom
Mark Boyd is a writer and API industry analyst, who writes regularly for 
ProgrammableWeb, and The New Stack. He has chaired several API 
conferences, and published a number of ebooks on the API lifecycle, best 
practices for API adoption, and API uptake in industry verticals.
2018 State of API Integration Report
5
Introduction
S E C T I O N  1
2018 State of API Integration Report
6
The State of API Integrations
As we learned in last year's State of API Integration Report, the fast-paced world of SaaS Applications 
and app development is nothing without advanced API integration. Not only have APIs become a 
necessity for application customers to streamline operations across their business and product suite, 
they have become an integral part of product development, business strategy, and scalability. As a 
result, customers will continue to seek out applications and APIs that can be easily integrated.
 
It's no longer sufficient to offer a standalone, isolated productdevelopers must build flexible 
platforms that not only offer highly functional APIs, but also integrate seamlessly to the ecosystem 
of products and services used by their customers. APIs are the foundation for this network effect, 
and must continue to evolve to meet the expectations of developers. The role APIs and API-based 
integration need to play in creating a customer-centric platform is a key theme we discovered in 
building this year's report. 
The proliferation of applications and subsequent API-based integration demands that developers 
now consume and build against a multitude of endpoints, languages and platforms. To develop a 
top-down view of this rapidly growing network, we surveyed hundreds of application developers for 
feedback on their own APIs and their experience with others they work with. We've distilled all of 
that information into the most noteworthy stats, changes and trends in our comprehensive State of 
API Integration 2018 Report.
Not only have APIs become a necessity for application 
customers to streamline operations across their business 
and product suite, they have become an integral part of 
product development, business strategy, and scalability.
S E C T I O N  1
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
7
Important Findings:
Building Platforms Instead of Products
This report will cover key findings from the survey we distributed to collect insights into the state of 
API integration. It will share our predictions on how these findings will change the industry in 2018 
and beyond. We will explore prominent themes, including the expectation that APIs ease integration, 
rather than stifle it, and that successful applications should be more like platforms than products.
For example, 36% of respondents stated that their primary motivation to become a platform provider 
was sparked by their desire to maintain 'stickiness' with customers by integrating easily across the 
ecosystem of applications. 
While most companies "considered themselves a true platform provider," one-third of respondents 
said they offered pre-built integrations for non-technical users. Without such an option, customers 
with little-to-no development experience will struggle to build their own workable integration
limiting the network effect of that platform. This report helps define what truly constitutes a flexible 
'platform,' and the implications that this definition has on the industry.
Our data also exposes the growing desire for innovation in event-driven integration: 
Nearly 40% of those surveyed responded that their apps did not support 
event-based framework, but it was the number one answer when we asked which 
API technology area was most in need of innovation. 
While this architectural pattern is enjoying something of a resurgence - as it reduces coupling 
between services and provides a far more efficient way of synchronizing and updating data - work 
still needs to be done amongst API providers to embrace event-driven capabilities. Find even more of 
these key observations in the following sections! 
While most companies "considered 
themselves a true platform provider," 
one-third of respondents said they 
offered pre-built integrations for non-
technical users.
Section 01     |     Section 02     |     Section 03
34.4%
2018 State of API Integration Report
8
Looking Ahead in the World of APIs 
The report also gives us an opportunity to look forward to 2018 and beyond, and predict new trends 
in the API space, including:
 Connecting to an API, and truly integrating with an API are not 
the same - developers and API providers alike must consider all 
aspects of integration and find ways to standardize and simplify 
this process. 
 Applications should focus on developing 'stickiness' and the ability 
to easily integrate to other products and partners in order to stay 
competitive in their markets and drive both new and renewed 
subscriptions.  
 The continued growth of public APIs that are open to any 
developer will be paired with pre-built integrations that non-
technical consumers can implement easily to streamline 
processes.  
 Developments will be spurred in particular by verticals like FinTech, 
Banking, Healthcare and Human Capital Management.  
 Further support for event-based integration, which is a feature 
commonly requested by developers, but that has commonly been 
unavailable for apps currently on the market.
This introduction serves only as a high-level overview of the results we collected 
from our State of API Integration survey. Keep reading to get the full breakdown on 
the current state of the API industry, a look at what's trending and why, and a look 
ahead to where we believe API integration is headed. 





Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
9
"
I've been watching the technology, business, and politics of APIs in 
a full time capacity since 2010, and the biggest trend I am seeing 
in 2018 is that it's no longer a conversation about whether or 
not businesses should be doing APIs.  In 2018, it is expected that 
you need APIs to do business in this digital age. The companies, 
organizations, institutions, and government agencies who are just 
beginning to invest in their API infrastructure are quickly realizing 
how far behind they are when it comes to the efficient delivery of 
data and content to web and mobile applications, as well as the 
ability to work with Internet-connected devices, and take advantage 
of the benefits of machine learning and artificial intelligence. 
However, the platforms who have been investing in their API 
platforms for the last couple years are shifting their focus towards 
increased investment in event-driven architecture, and an API 
governance strategy to further optimize and maximize on their 
earlier investments. To be able to operate their platforms at scale, 
API providers have embraced a microservices-centered, robust 
lifecycle approach to delivering their APIs, with an OpenAPI-driven 
definition acting as a central contract. Providing a blueprint for 
designing, deploying, managing, and properly integrating, and 
extending each service to wherever it is needed, no matter where 
that might be. Providing the machine readable gears that are needed 
for the automation required as part of an ongoing organizational 
digital transformation.
The API 
Landscape of 2018
Contributed Content from Kin Lane, API Evangelist 
2018 State of API Integration Report
10
In 2018, OpenAPI has become the contract for doing business 
with APIs, and is key to API providers efficiently delivering and 
managing their growing number of microservices. This contract is 
being used to manage the platform, but also ensure that services 
properly reach outwards to API consumers with up to date API 
documentation, robust SDKs, IDE integration, and API discovery 
solutions for developers. These contracts are also being used to 
drive spreadsheet integrations, Salesforce connectors, and the 
growing number of integration services that have emerged on the 
landscape to help non-developers take better advantage of API-
driven resources. OpenAPI definitions are the technical, as well as 
business contract for mature API platform providers, allowing them 
to manage their APIs at scale, and reach a technical as well as 
business audience.
With machine readable contracts in play, driving an increasingly 
automated lifecycle, API platforms are looking to further refine 
their API governance strategy, helping ensure the continued 
delivery of highest quality APIs at scale. When this is combined 
with a heightened investment in real time streams of information, 
event-driven infrastructure, and the development of relevant 
machine learning models, API industry leaders are looking to shift 
their platforms into high gear. 
This all makes the conversations around whether or not we should 
be doing APIs a distant memory, turning hard fought lessons 
around delivering, integrating, and aggregating APIs into the fuel 
for the next round of investment in event-driven architecture, 
machine learning and API governance that will help drive business 
growth for the next decade.
2018 State of API Integration Report
11
Which industry are you in? 
While the majority of repondents are technology companies, our metrics represent at 
least 27 distinct industries
Behind the data
Technology  -  137  Media 7Manufacturing  7Entertainment  7Retail  9Healthcare  9Government  9Transportation  10Education  12Other  43Banking  13Engineering  15Communications  20Consulting  23Finance  36Section 01     |     Section 02     |     Section 03
Last year, Cloud Elements released the first ever State of API Integration report, which analyzed data 
from within the Cloud Elements API Integration platform, including over 1.6 billion API calls to 160+ 
endpoints.
We are taking the 2018 report to the next level. 
This year's report expands upon the data from the Cloud Elements platform, featuring data collected 
from 400 companies, in 27 distinct industries, with annual revenues ranging from less than $100,000 
to over $25 billion. Collectively, these participating companies spent 200,000+ development days 
building over 4,500 API integrations in 2017. Our inaugural State of API Integration survey was 
distributed between September 2017 and March 2018 to representatives of these companies. Their 
responses contributed to the identified trends surrounding the existing demand for API integrations 
and the roadmap for leveraging integrations in the future.
The report also includes industry expert insights from Ross Garrett, VP of Marketing at Cloud 
Elements, Kin Lane, The API Evangelist, Mark Boyd, writer for The New Stack and ProgrammableWeb, 
and Isabelle Mauny, co-founder and CTO of 42Crunch.
2018 State of API Integration Report
12
The 2018 State of API Integration 
Survey Respondents
Integrating the 
World of APIs 
The analysis in the 2018 
State of API Integration 
report represents data 
collected from companies 
across 44 countries and 
6 continents
43%
CTO
5%
CIO
4%
Partner
3%
Product
2%
Sales
2%
Marketing
36%
Executive
7%
Developer
What is your position? 
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
13
Trends in API 
Integration
S E C T I O N  2
2018 State of API Integration Report
14
Trends in API Integration
As the number of public and private APIs grow month over month and year over year, it's no surprise 
that at least 85% of organizations we surveyed consider Web APIs and API-based integration 
fundamental to their business strategy and continued success. Of these, more than 60% have 
invested in a public facing API and the surrounding infrastructure to manage access for developers 
and partners.
Building a Platform Strategy: 
How to drive new revenue opportunities 
or deliver value through API integration.
Strategic Shift of Integration: 
How API integration has matured to 
enterprise applications like ERP.
Drivers of Adoption: 
Changing how developers and end-users 
consume APIs and integration services.
Evolution of B2B Integration: 
Organizations are evolving the way they 
share and synchronize data with partners.
1
3
4
2
Over 60% agree, API Integration is 
critical to their business strategy.
S E C T I O N  2
2%
0
4%
1
9%
2
24%
3
61%
4
Not at all
Critical
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
15
Building a Platform Strategy 
Today's most successful software companies have made the leap from selling products to selling a 
platform. The appeal of such a move is understandable: software products generate only a single 
revenue stream, while platforms, by connecting different groups of users and services, can generate 
multiple revenue streams.
Our survey responses demonstrated that more than half of organizations today would consider 
themselves to offer a platform or to be on the path to offering a platform. Of those that don't, it's 
important to have a made a conscious decision in this regards - hope is not a strategy, and many 
product organizations are being disintermediated for moving too slowly in this regard.
1. Single-sided business model limits your company's growth 
and longevity. You're simply delivering a product in the way that 
you always have, to the customers you always have, without really 
thinking about the network around your organization.
2. Multi-Sided Business Models take that a step further. In 
this model, a platform company enables other businesses to 
interact with your technology in order to build new services and 
applications.
3. Third party integration can create greater adhesion, stickiness 
and relevance across your market.
Do you consider your organization 
a platform provider? 
Platforms enable a multi-sided business model that can be a 
key driver of growth:
57%
Yes
43%
No
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
16
Model A 
Basic Usage Metering 
 
This is the most obvious method of generating revenue from your APIdirectly charging for it. This 
strategy works best if your organization provides access to data or services that people want to pay for.
Model B 
Upselling API Integration 
SaaS providers use this model often, as customers have become increasingly demanding of 
integration capabilities for any product they buy. Adding API integration to a subscription offers a 
strong motivator to upgrade to a higher package, and creates a stickier relationship with customers 
by allowing end users to customize their experience and workflow more easily.
E.g. Dun & Bradstreet is a data provider, and expose data as a service via API. In this 
case, customers are willing to pay for programmatic access to D&B's services to 
enable new business processes and products around the D&B platform.
E.g. Concur provides pre-built integration options with their product, so that 
subscribers of the service can easily synchronize expense management data with 
ecosystem of apps used in their back-office processessuch as accounting and ERP 
systems.
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
17
Model C 
APIs as a Product 
APIs that are themselves the product can be the most complex monetization models, but they also 
often provide the highest valuecollecting some revenue share or service-based fee for the product 
delivered via API. 
E.g. Paysimplea leading payment gateway provideroffers API access to their 
payment services. Customers of this service will then be charged a percentage of the 
payment amount for each API transaction.
Model D 
Distribute Value through Partners 
 
Organizations can scale the reach of their product by integrating their API with strategic partners. 
This has the potential to open your business to existing application ecosystems which you may not 
be able to reach alone.
E.g. Sage works with various ISVs to distribute their products and services as part of 
a broader offering. This network effect has enabled them to achieve the scale and 
growth that would be difficult in a direct sales model.
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
18
While these are only examples, each describes a path towards revenue growth and 
ecosystem expansion with APIs. We expect that leading platform providers will 
leverage more than one (if not all) of these models as they grow.
Ultimately, a move toward "best-of-breed" is on the rise - meaning that every product, 
in every vertical, is better served by enabling integration to the ecosystem of apps 
around them rather than remaining a hermetically sealed environment.  Over the 
coming year, we anticipate to see more of the world's successful software companies 
continue to make the leap from selling products to selling a platform.
Model E 
Improve Operational Efficiency
API integration can help you build end-to-end solutions more efficiently. They help you 
innovate faster, engage customers and partners faster,and perhaps most importantly, they allow 
you to iterate (and even fail) faster. The time taken to build or automate business processes can 
easily improve from a couple months to a couple hours, solely because of the efficiency gained 
from an API integration.
E.g. Microstrategya leading business intelligence platform provides pre-built 
integration to several leading enterprise SaaS applications, so their customers can 
quickly access and integrate the data they care about without needing to build 
anything from scratch.
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
19
Drivers of Adoption 
This report paints a picture of hockey stick growth and untold opportunity, but the growth in 
APIs hasn't come without challenges. Many application providers, businesses and even platform 
companies reported concerns around API adoption.
Issues with API adoption can be related to developer experienceAPI style, documentation, 
functionality, etc. But the real issue is far more systemic than DX. Adoption is limited by the 
addressable market, i.e. the number of developers that are available to learn, build against, or even 
care about your API!
Our 2018 survey points to evolving and increasing need in the world of API 
integration, creating a possibility for non-technical users to build the workflows 
they need. By offering "no-code" or "low-code" capabilities, we can massively 
expand the total addressable market for APIs and instantly solve the common 
adoption concern.
How Organizations are Driving API Adoption Today 
(Respondents selected all that apply)
Public API, open 
to any developer
56%
42%
60%
35%
Platform that 
enables 
developers to 
build integrated 
services
Pre-built 
integrations that 
non-technical 
users can 
leverage
SDKs to ensure 
integration is 
easy for 
developers
Ease of Use
Easiest
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
20
Customized APIs
One Size Does Not Fit All 
As API integration evolves and matures, it has become very clear that not all API consumers are 
created equal. Data objects may need to be modified based on the device type; orchestration or 
composition may be needed depending on the sophistication of the client; security might need to 
be adapted to fit mobile, web, or IoT scenarios. The list goes on.
What is the highest demand from your 
customers and partners for API integration?
Other
13%
2%
19%
19%
47%
Customized APIs that fit 
a specific business need
Better 
documentation
"No Code" 
integration 
templates
SDK wrappers 
for APIs they 
need and use
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
21
With each new innovation in connected devices, and each new user and application experience that 
accompanies these devices, organizations must consider an application architecture and integration 
strategy that embodies flexibility and agility. API mediation is becoming a more familiar concept as 
many organizations begin to evolve beyond their first foray into the API Economy. 
API mediation is a solution for enriching or personalizing interactions between distributed 
application and service components. We like to call this API Experience Management. The key to 
the API experience model is placing a new mediation or abstraction layer between API consumers 
(apps, services, and "things") and API providers (services and applications). This layer wraps the 
backend API (the inner API) and exposes a personalized and managed API (the outer API) to each 
defined constituency of consumers, simplifying the developer experience while also ensuring loose 
coupling.
 
The new outer API may also aim to offer more advanced features to your developers, providing a 
facade on top of the inner API to enhance its functionality, or simply keep pace with changes across 
API technologies and best practices.
A great example of this diversity comes from Netflix, where their API development 
team learned quickly that a "one-size-fits-all" approach to API integration wasn't 
going to work. The team found that different client applications (such as a desktop 
browser, a mobile application or a smart television) required different functionality as 
they accessed the Netflix API, thus forcing the API team to build an increasing number 
of features to address the demands. Once continuously updating this single interface 
became unmanageable, they introduced an API experience, or mediation, layer on top 
of their existing API platform that allowed each UI team and even partners to optimize 
the API experience for their specific app or device.
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
22
The burgeoning Low-Code/No-Code space has become an extraordinarily disruptive force in the 
domain of API integration - causing confusion amongst developers, users and even vendors. But 
even the terminology itself can be misleading, as the distinction isn't about whether people need 
to code or not - but rather about the types of people using technology and tools to build API 
integration
Representing the "No-Code" domain are the "citizen integrators"an analyst term to mean business 
users who can build functional, but perhaps simplistic workflows without having to write a line of 
code. 
In the "Low-Code" domain, we focus on developers instead, demanding platforms to help 
streamline and simplify their workdelivering enterprise-grade API integration without having to 
start from scratch.
Twenty years ago, application integration was implemented by hundreds of consultants and experts 
at a multi-million dollar cost. Now, with no code/low code, the same integration use cases can be 
implemented at a fraction of the price and in a fraction of the timeand users expect it.
API providers must start to deliver more tooling that expands their addressable market, makes it 
easier to get started quickly and transfers the burden away from the application buyer.
Source: Gartner 2017
Inner APIs
Out
er APIs           Out
er APIs           Out
er APIs           Out
er APIs           Customers
Applications
Things
IT Systems
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
23
Strategic Shift of Integration 
Integration is all about making different apps and systems work together. Allowing them to share 
data, orchestrating business workflows, and coordinating how users work across growing number of 
apps. 
As the app ecosystem developed, it spawned a new world of API-based integration and a landscape 
of integration platforms aimed at helping developers manage how their applications interact. Now, 
as API integration matures, the requirements, technology and integration use cases have also 
matured. Many organizations must now work to integrate both their new SaaS applications and 
legacy systems in the same developer friendly environment.
Integration Needs Comparison
Internal Needs within an Organization vs.  
External Application Needs by End Customers
Database
21%
internal
external
16%
ERP
16%
internal
external
13%
Finance
11%
internal
external
9%
Communication
11%
internal
external
11%
Marketing Automation
10%
internal
external
12%
CRM
18%
internal
external
23%
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
24
SaaS has dramatically changed how we purchase, consume and adopt softwaremaking business 
apps easy to buy, use, and maintain. As a result, application integration has become a differentiating 
factor of every business, not just a tool. Today, an average enterprise uses 1,181 cloud apps across 
its entire organization (source: Netskope, Feb 2018). This is a stark contrast to the 1990s, where an 
average enterprise used 5-10 enterprise apps.
API integration is centered around adopting best-of-breed apps and systems by enabling smart, 
fast, adaptable integrations and automations across all of a company's apps, APIs, data, people and 
devices to deliver innovative, personalized experiences.
For API integration that means the way businesses work has drastically changed from the days when 
traditional integration tools were created. Business apps have become consumerized, self-service, 
and low-cost, but the tools to integrate these apps often remain complex, technical, and sometimes 
more expensive than the apps they are integrating. 
Integration tools should be flexible, allowing integrations to be changed at any time. In the past, 
integrations were 'built-to-last'. Once you have your Order-to-cash process going between your 
SAP and Salesforce, you don't go back to change itthe requirements were more stable. This is 
no longer the case. Business apps and the processes and workflows around them are constantly 
changing as new apps are added and existing apps are changed. Constant change is the norm, 
requiring organizations to think strategicallynot tacticallyabout API integration.
In short: traditional integration platforms may be powerful, but they are limited by the apps they 
support, the number of use cases they support, and who can use these platforms. These limits are 
the reflected on the entire organization, making it impossible to enable enterprise users to build 
integrations that support their line of business, to offer embedded integration experiences their 
customers need, or to build the products their organization needs to survive in the digital era.
SaaS has dramatically changed how we purchase, 
consume and adapt softwaremaking business apps 
easy to buy, use, and maintain.
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
25
While traditional B2B integration via EDI and other similar interfaces is expected to remain a large 
part of the partner collaboration market for the next few years, API integration technologies are 
seeing growing adoption across many industries. By migrating to API-centric partner integration, 
or adding this option to existing business processes, organizations can deliver the same quality of 
service with much less overhead.
APIs offer an easy way for companies to establish these essential integrations with customers and 
other businesses. There are 2 key areas B2B integration strategy should consider:
New Digital Products Being 
Developed in 2018 
Evolution of B2B Integration 
Businesses are not islands. Connectivity, collaboration, and success with partners and customers 
is the lifeblood or fuel that drives any organization. Providing a way for these partners to access 
your products, and exchange information is fundamental. However, many organizations still rely on 
outdated and outclassed B2B infrastructure to exchange this crucial information. Partner integration 
in 2018 and beyond requires a different approach. Web APIs not only deliver more flexibility and 
speed, they will also enable you to attract and connect many more partners and customers than 
today. During 2018, more than 50% of all B2B collaboration will take place via API integration, and 
prospective partners will expect that they can integrate with your business via a lightweight API-
based approach.
This trend is reflected in our survey results, showing that 65% of respondents are developing new 
B2B products and B2B API integration solutions.
65%
B2B products
39%
Mobile 
products
36%
B2C / 
Consumer 
Products
27%
Employee 
productivity
23%
IoT 
Applications
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
26
Flexibility 
By allowing a multitude of companies to leverage your platform for a variety of use cases, your 
company can open the door to a larger market segment. Think about how your customers or 
product teams consume your API. What level of burden are you forcing upon your customers? 
Would better documentation allow people to integrate with your business better? 
One of the biggest mistakes you can make is assuming that your API offers all of the utility that every 
persona might require. In fact, our survey shows that many developers take weeks to complete an 
integrationand every day spent is lost business value.
Average Number of Days to Build 
Net New API Integrations
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
27
Longevity 
According to Constellation Research, 52% of the Fortune 500 have merged, been acquired, gone 
bankrupt, or simply fallen off the list since 2000. In order to survive in the API economy, you have to 
think about longevity.
To set yourself up for success, it's important that your organization can support a wide variety of 
use cases in a dynamic market. The narrower your supported use case, the less likely your company 
will last in an ever-changing environment. As use cases and needs change it's important that your 
company has a wide enough lens to adapt in real-time. The best way to widen that lens is learning 
from the ecosystems and the partners that you do business with.  By quickly integrating into multiple 
application ecosystems you diversify how similar use cases are used in different environments,  
increasing your stickiness and preserving your longevity in the market.
Offering Integrations Leads to More Revenue
Majority (64%) agree that at least a quarter of their user base will upgrade or 
renew, if they offer integrations
64%
> 21%
15%
11-20%
13%
6-10%
8%
> 5%
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
28
Summary 
API integration is no longer just for 
developers. Businesses can leverage 
platforms to drive various competitive 
advantages and achieve long-term success.
It is important to consider how your 
organization interacts with all segments of 
your customer base, delivers and consumes 
value in the surrounding ecosystem, and 
thinks strategically about integration.
S E C T I O N  2
2018 State of API Integration Report
29
Developer API 
Integration
S E C T I O N  3
2018 State of API Integration Report
30
Event-Driven Integration
Based on our research, one sentiment is clearmany architects and developers 
have high interest in and adoption of event-driven integration.
Most organizations aim to create their own "Composable Enterprise" and will rely on multiple cloud-
based services to deliver this vision. Yet, many of these SaaS applications are islands that haven't 
been optimized for integration, and many developers depend on pollinglots and lots of pollingto 
create the workflows and integrated scenarios they need. For many application providers, there is a 
long way to go before they can offer the features and event-driven capabilities developers expect. 
Real-time demands are driving event-driven requirements
The need forand increased interest inevent-driven architecture is arguably attached to the 
demand for real-time application integration and data movement. The world of "real-time" is 
perhaps misunderstood, used in the wrong context or at best an overloaded term where the 
tolerances for delay or latency vary based on the use case.
 
There can be varying opinions on the definition but in this case, 'real-time' implies web technologies 
that enable applications to react to relevant business events as they happenor at least within an 
understood period of latency. (e.g. 4ms delay may render a financial trading platform uncompetitive, 
while 400ms delay is easily tolerable for most application integration use cases.)
S E C T I O N  3
Developer API Integration
Today's software architecture draws together a complex web of internal and external services 
to deliver new value to customers at a lightning pace. Any successful, forward-thinking business 
today leverages the power of APIs to integrate a wide range of services, data, external providers 
and internal business capabilities into new workflows, mobile applications, and customer-facing 
products.
However, as application and end-user demands evolve, this architectural approach also comes with 
challenges. In this section we'll discuss 3 key architectural concerns you should consider when 
building, integrating or managing your APIs.
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
31
Event-driven technology
The good news is there are a variety of technology options and architectural best practices available 
to embrace real-time integration. The WebSockets standard is now well established as an efficient 
mechanism to stream data in real-time, and Webhooks is gaining momentum as the protocol 
and pattern of choice for event-driven APIs. The arrival of HTTP 2.0 and Server-Sent Events also 
represent an ever evolving landscape of technologies that may be used in other event-driven use 
cases.
WebSockets
WebSockets provide a richer protocol to perform bidirectional, full-
duplex communication. This two-way channel is more attractive 
for things like games, messaging apps, interactive experiences, and 
for cases where you need real-time updates in both directions. But 
again, the solution isn't perfect as the integration pattern effectively 
breaks the semantics of HTTP.
Server-Sent Events
First-off, the term Server-Sent Events (SSEs) may be unfamiliar for 
many. For the past few years the specification has been in a state of 
flux and overshadowed by the more fully featured communication 
protocol - WebSockets. However, the idea behind SSEs should be 
familiar: allowing a Web Application to "subscribe" to data updates 
originated (sent) by a server, and subsequently be notified as these 
data events occur. The problem with SSEs is that, while they remove 
the polling technically, they also take much of the control from the 
user and forces the user into a passive state.
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
32
Over the past 18-24 months there has been increased chatter about the limitations of Web APIs, 
and how architectural choices must be made on merit versus conceptual elegance. This has led to 
the evolution of standardssuch as v3.0 of Open API Specification, which now includes a way to 
document Webhooks as part of a RESTful API.
Webhooks
Webhooks work by automatically posting new event data to a user-
defined URL, which is monitored by the user's linked applications. 
Each time a new event is posted to the URL, the linked applications 
update to include the new data. Unlike polling, which delivers 
usable data on less than two percent of requests, webhooks only 
update when new information is available. Because of the increased 
efficiency, over 82 percent of developers surveyed by Wufoo 
indicated that they would rather receive new data via Webhooks 
instead of with polling. Despite this preference, our research 
revealed only 29 percent of APIs currently support webhooks.
Developers Prefer 
Webhooks Over Polling
Over 82% of developers surveyed 
by Wufoo indicated that they 
would rather receive new data 
via Webhooks instead of with 
polling. Despite this preference, our 
research revealed only 29% of APIs 
currently support webhooks.
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
33
Our Recommendation
There is no single design decision that perfectly answers every integration question, but the perils 
of polling are clear: higher network overhead, increased cost and poor user experience. Our 
recommendation is to consider alternatives like Webhooks when building your next Web API or 
integration scenario.
One clear signal emitted by the strongest API providers across 
landscape in 2018 is the importance of investing in event-driven 
infrastructure, and the development of a real time perspective of 
getting business done using their API-driven infrastructure. The 
phrase event-driven will mean different things to different providers, 
but generally it reflects the ability to respond to internal, partner and 
consumer needs in real-time, as events around valuable resources 
occur.
Event-driven infrastructure might involve the development of 
Apache Kafka pipelines within the enterprise, the delivery of financial 
market data to web and mobile devices using Server-Sent Events 
(SSE), all the way to pushing data and content via webhooks as 
resources are added, updated, or even removed via APIs. API 
infrastructure has historically been centered around making the 
resources they have available in the web, mobile, and device-based 
applications. Event-driven API infrastructure is about making sure 
An Event-Driven API 
Landscape Driving What 
Matters To Consumers
Contributed Content from Kin Lane, API Evangelist 
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
34
the most meaningful, valuable, and relevant information is delivered 
when and where they are needed--driven by API consumer's needs 
and desires, moving the conversation beyond just what resources 
API providers have available, and making it about what consumers 
need.
When you watch what the most seasoned, and mature API providers 
are investing in across the landscape in 2018, you hear stories about 
Yelp or Pinterest's investment in Kafka infrastructure internally. You 
also see Stripe, and Slack adding further to the list of webhook 
events that their API consumers can subscribe to. Event-driven 
signals are a sign of platform maturity, and that API providers are 
moving beyond the early stages of their development, having seen 
the traction and adoption that they were seeking. These providers 
are now interested in cutting through the noise and distortion, and 
ensuring that their API consumers are subscribing to and in tune 
with the most relevant events that are occurring via the platform at 
any moment.
Event-driven architecture isn't just about data firehoses and 
pipelines, or real-time streams. It is about making sure your platform 
is pushing beyond the basics of API operations, and is managing 
and moving around data, while applying algorithms in the most 
efficient and meaningful way possible. Realizing an event-driven 
way of doing APIs isn't about the next trend in doing APIs, it means 
you are mastering the regular aspects of platform operations, and 
have begun investing in the next stage of its execution, speeding up 
the delivery of resources, and optimizing their orchestration. Event-
driven APIs aren't just about being able to technically deliver in real 
time, it is about being able to do business in real time, responding to 
what matters, as it occurs.
2018 State of API Integration Report
35
Emerging API Styles 
As the API integration landscape evolves, new API styles such as OData and GraphQL are emerging 
and gaining ground amongst developers. Here we'll evaluate each of these with regards to achieving 
interoperability across APIs for analytics, integration and data management.
What is OData? 
Originally developed by Microsoft in 2007, 
OData is an OASIS standard REST API well-
established among companies such as 
Microsoft, SAP, IBM and Salesforce. It allows 
the creation and consumption of queryable 
and interoperable RESTful APIs in a simple 
and standard way. OData gives you a rich set 
of querying capabilities and is quickly gaining 
ground for its open source approach, as well 
as its exceptional scalability.
What is REST?
REST (representational state transfer) or RESTful web services are one way of providing 
interoperability between computer systems on the internet. REST-compliant web services allow 
requesting systems to access and manipulate textual representations of web resources using a 
uniform and predefined set of stateless operations. RESTful implementations make use of standards 
such as HTTP, URI, JSON and XML.
It's important to note that REST is an architectural style, not a standard.
What is GraphQL? 
Developed internally at Facebook in 2012, 
before public release in 2015, GraphQL 
is a data query language deployed at 
companies such as Facebook, Shopify and 
Intuit. GraphQL provides a complete and 
understandable description of the data in 
your API, gives clients the power to ask for 
exactly what they need, makes it easier to 
evolve APIs over time and enables powerful 
developer tools.
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
36
 
The table above highlights common criteria for accessing data through open standard interfaces. 
OData has the full range of support for all these query capabilities. You can do some of these 
operations with GraphQL, but they're not standardized or documented in a way to achieve 
interoperability. 
GraphQL is much like REST in that it defines the way to interact with a web service, but it doesn't 
tell you what the service does. So you can do filtering, ordering, and joins, etc, but the application 
developer has to understand how those work semantically to be able to know what their behaviors 
are.
API Versioning and Maintenance 
One key area of maintenance is handling updates to applications when the API changes, while 
maintaining older versions. The biggest problem leading to this dilemma with REST APIs is that all of 
the fields are returned when you query an endpoint. API providers have no visibility into whether or 
not clients are relying on information in specific fields. API consumers must process all of the fields 
returned even if they do not need the information.
GraphQL has addressed the problem of API versioning and maintenance by forcing clients to specify 
exactly which fields they require.
OData provides similar functionality by providing a select list to limit the number of fields returned 
to those needed by an application. This reduces response size and processing in an application. 
However, it does not provide a mechanism to indicate that fields are deprecated.
Section 01     |     Section 02     |     Section 03
Query Capabilities: OData vs GraphQL
Operations
OData
GraphQL
Filtering
Ordering
Aggregation
Joining
Paging
2018 State of API Integration Report
37
GraphQL has already seen rapid adoption since its public release in 2015. 
Production use cases from enterprise, government and startups are already in 
place and new tooling continues to evolve and diversify. As an API technology, 
GraphQL is finding its place in the broader API market landscape and has potential 
to strengthen adoption by leveraging two other API sectors: in Serverless and in 
the Internet of Things.
While sectors like ecommerce and publishing are already seeing significant value 
from moving to a GraphQL API architecture, this year is starting to see other 
industries take notice, particularly online video services. Key early user segments 
in marketing technology, software development tooling, and digital consultancies 
will help spread adoption to other industries.
One of the key benefits of GraphQLthe ability to create a data abstraction layer 
that can combine multiple sources through a single gateway and endpointwill 
garner growing interest from industry sectors that have complex data supply 
chains. Data science, healthcare, and city services will be drawn to GraphQL in 
2018 in the same way that publishing, social media and ecommerce have been to 
date.
GraphQL has quickly established itself as a valid option for businesses and 
developers making choices around how to create and manage their API strategy. 
Across the sector, the biggest gap is a matrix decision tool that allows API creators 
to assess each type of API architecture option and weigh up the best cases each is 
suited to implementing. Without this clarity, each individual business must do their 
own research from REST, Hypermedia and HATEOAS, SOAP and GraphQL options.
For many use cases, GraphQL has the potential of leapfrogging the growing 
interest in hypermedia APIs. In hypermedia APIs, responses describe what data and 
links are available so that as queries are made, an application can discover what 
other data and capabilities are available that are relevant to the application's need. 
GraphQL: Changing the 
Landscape of APIs
Contributed Content by Mark Boyd 
2018 State of API Integration Report
38
In hypermedia, this requires good metadata and well structured endpoint linking, 
but can return bloated responses that slow down an application's performance. 
In GraphQL, the schema itself describes the full data model. The introspection 
quality means that inside any GraphQL API is the ability to query its own data 
model to better understand what data is available. And GraphQL's advantage of 
allowing clients to only call the specific data that is needed avoids hypermedia's 
bloat problem.
As an abstraction layer that is able to draw in multiple data sources and make them 
available or referenced within a single schema/data model, GraphQL has huge 
potential for use in sectors where data comes from disparate and disconnected 
sources. GraphQL removes data access barriers and makes all dataregardless 
of the original owner or place of publicationavailable through a single schema 
where relevant, related data can be queried at the one time. This suggests that 
the fields of data science, healthcare, city services and other sectors that manage 
complex relational data models may see advantage in adopting GraphQL.
There is no doubt there are still some challenges GraphQL must solve. More 
complicated operations such as writing data in bulk, managing real-time data 
querying via a subscription rather than polling mechanism, and managing caching 
and pagination are partly solved but require more testing against production use 
case needs. Authorization stands out as one area of work that requires significant 
additional tooling and a variety of options.
Ultimately in 2018, GraphQL's evolution is still in its infancy, but with the rapid 
interest from developers and the quick iteration and availability of tooling, there 
are strong signs that GraphQL is becoming a legitimate option for how APIs are 
created and managed, offering significant performance and developer experience 
benefits. 
2018 State of API Integration Report
39
API Security 
APIs are certified "cool" - they provide access to data and services otherwise locked behind 
corporate firewall, they enable easy development of web & mobile products, and they allow 
organizations to do business in new ways. But this strategic opportunity opens up vulnerabilities, and 
APIs are becoming the primary attack vector for unscrupulous individuals, organizations and even 
governments!
Security then, must be a leading concern. All API stakeholders (developers, architects, operations 
and the business) must play a role in deploying a security model that both enables and protects. This 
is a list of guiding principles that API projects should follow:
1.
Security features, like deciding how to deal with authentication and 
access control is often relegated to the last design consideration. 
But a robust security model must also consider your overall 
application architecture and find all layers where threats and 
vulnerabilities may exist. It's also important to think about reusability 
in your security architecture, making it easy for developers to 
leverage standardized mechanisms at each application tier.
2.
Basic access control is actually pretty 
simple. Users and clients request to 
access Objects like data, applications 
and services. Access controls then 
make a decision to grant or deny that 
request. Today, user management is a 
mature space and most organizations 
have a central user directory. Object 
management must reach this same 
maturity, enabling better controls and 
improved granularity across your APIs 
and data model. Leverage existing 
standards (E.g. OAuth 2.0) to grant 
granular access to services.
3.
Many believe security architectures 
are focused on keeping the bad guy 
out, but in fact most often the inverse 
is true. Access control infrastructure is 
designed to provide a user experience 
to authorized entities: employees, 
customers, etc. It's important to 
design for malice: assume that those 
trying to gain unauthorized access are 
in fact not "playing by the rules", and 
instead finding ways to work around 
the areas governed by policy.
Section 01     |     Section 02     |     Section 03
2018 State of API Integration Report
40
Section 01     |     Section 02     |     Section 03
4.
Users simply don't care about or 
understand securitythey just want 
easy access and peace of mind that 
their data is secure. Unfortunately, 
for a long time security measures 
and technologies have delegated 
far too much responsibility to the 
end user, expecting them to make 
educated and technical decisions. 
How often have you been asked "Do 
you trust this certificate?" in a web 
browser? It's not practical to assume 
users have the technical knowledge 
to understand PKIso how is it 
reasonable to push this responsibility 
to them? API security should be 
designed in such a way to balance 
user experience and security.
5.
Developer experience is just as 
important as user experience, and 
knowledge around security can be 
dangerously lacking here too. API 
consumers can't be expected to 
know security, meaning your APIs can 
unwittingly create vulnerabilities by 
not arming developers with sufficient 
knowledge. For example, a developer 
may hit an API too many times and 
degrade performance. Or a developer 
may not know why or how to protect 
API and session keys. These can 
result in Denial of Service, and other 
security issues.
6.
Finally, API integration patterns are evolving, and while request/
response still makes up the lion's share of implementations today, 
there are other models that need to be secured as well. With 
an increasing preference for Webhooks, Server-Sent Events and 
WebSockets, the client-server designation is becoming blurred. 
Signatures and encryption (E.g. TLS) should be considered to help 
protect these bi-directional integration patterns.
2018 State of API Integration Report
41
APIs are doorways that have enabled organizations to build new connections 
into their monolithic software and data systems. Of course, doorways work in 
both directions. So while an enterprise may expose its data assets and business 
capabilities using APIs, they are also making extensive use of external services in 
their own systems by relying on APIs from third parties. 
This multiplication of endpoints has blurred the security perimeter of the 
organization. The threat surface has increased and more security risks need to be 
managed. A manual, ad-hoc approach to securing the numerous and evolving 
endpoints simply does not work. Furthermore, when API security is tedious and 
not agile, it is considered as a roadblock to quickly delivering apps and innovations 
and therefore often left out of development and operational discussions.
To address both issues, security teams must deliver "security as code", that is, 
translate security requirements into code that can run automatically at every 
step of the API lifecycle.  This can be done by taking a DevSecOps approach and 
"pushing security left", considering security aspects already when doing the initial 
design and defining requirements setting phases.
The DevSecOps mindset considers security issues as bug fixes. Security 
vulnerabilities are essentially bugs that can lead to unwanted outcomes in an 
application or a product. Like all bugs, you want to discover them as early as 
possible. The overall cost of fixing a bug is up to 30 times higher if discovered at 
production time rather than at development time.
DevSecOps Approach 
to API Security
Contributed Content from Isabelle Mauny, 
42Crunch
2018 State of API Integration Report
42
At design time, organizations must take these core actions 
to protect the APIs:
 Development, security and operations teams work together throughout the 
API design cycle, discussing and building the API contract (preferably based on 
open standards like OpenAPI), deciding where the API will be deployed, and 
who will use it. Together, they build the API's threat model that will drive the 
security policies to be applied to the API.
 
As APIs are designed, a set of pre-approved, pre-tested security policies are 
put in place that match the security level required. APIs are tagged depending 
on the risk evaluated as part the API threat modelling. The policies must 
address the core security aspects: 
 
 Enforcing the proper TLS settings to protect the API channels
 
 Validating the API contract and the flowing data
  Configuring the OAuth protocol and OpenID Connect 
authentication flows
  Auditing
  Non-repudiation
 
Encrypting and signing the API payload (optional)
To secure APIs during runtime, the following security 
aspects must be automatically enforced throughout the 
CI/CD pipeline: 
 
Security policies are incorporated as early as possible into the continuous 
delivery and testing processes, and an API security gateway is deployed to 
enforce those policies. 
 Code analysis tools (static and dynamic) are deployed and hooked to the 
CI/CD pipeline. 
2018 State of API Integration Report
43
 
APIs are actively scanned APIs for vulnerabilities, in other words: you must 
hack yourself! You can start with ZAP, an OWASP open source penetration 
testing tool that you can plug to the CI/CD pipeline. 
 Deployments are tested for proper TLS configuration using tools such as  
SSL Labs or securityheaders.io.  
 
Software and libraries are constantly kept up to date, and tools are put in place 
to actively monitor security vulnerabilities. 
 
Systems are constantly monitored for security alerts in order to respond 
promptly to attacks.
In addition, it is critical to educate personnel on security 
risks: all concerned parties should at least know about the 
top 10 OWASP risks list and how to address them. 
Protecting and testing your APIs through a repeatable, well-defined, automated 
process enables the enterprise to continue to innovate at the pace required to stay 
competitive, without compromising on security.
2018 State of API Integration Report
44
Interactive Calculator
Score the Current State of YOUR API Integration
To wrap things up, we wanted to give our readers an interactive calculator 
to gauge how your API currently stacks up against the current state of API 
integration. Gauge how easy it is for API consumers to interact with your service, 
and how easy it is for data to move between your service and other applications. 
Where do you stack up against the rest of the API community? Share your score 
and be sure to mention #StateofAPIIntegration. 
CLICK HERE TO SCORE YOUR API
https://hubs.ly/H0bq4kv0
2018 State of API Integration Report
45
Closing
And there you have it. We hope you enjoyed seeing the data and hearing 
from our contributors about the trends that are set to affect APIs and 
application integration. Follow the conversation by using the hashtag 
#StateofAPIIntegration.
Check out our resource center for other easy to follow information. If you have 
questions, or would like to learn more about Cloud Elements, contact us today!
CONTACT CLOUD ELEMENTS
</p>