Content uploaded by Jochen Wulf
Author content
All content in this area was uploaded by Jochen Wulf on Dec 09, 2019
Content may be subject to copyright.
1
Fostering Value Creation with Digital Platforms: A
Unified Theory of the Application Programming
Interface Design
Accepted manuscript version (postprint) and supplements
First author (corresponding author)
Second author
Name:
Jochen Wulf
Ivo Blohm
Affiliation:
Institute of Information Management
University of St.Gallen
Institute of Information Management
University of St.Gallen
Address:
Mueller Friedberg Strasse 8
9000 St. Gallen
Switzerland
Mueller Friedberg Strasse 8
9000 St. Gallen
Switzerland
Email:
jochen.wulf@unisg.ch
ivo.blohm@unisg.ch
Phone:
+41 71 224 3800
+41 71 224 3865
Cite as
Jochen Wulf & Ivo Blohm (forthcoming) Fostering Value Creation with Digital
Platforms: A Unified Theory of the Application Programming Interface Design,
Journal of Management Information Systems.
2
Fostering Value Creation with Digital Platforms: A
Unified Theory of the Application Programming
Interface Design
JOCHEN WULF is a lecturer at the Institute of Information Management, University of
St.Gallen, Switzerland. He was awarded a grant of the International Postdoctoral Fellowship
program while being an assistant professor at the University of St.Gallen. He obtained a Ph.D.
in Information Systems from the Technical University of Berlin, Germany. His research on
data-driven services, consumer-centric information systems, and IT service management has
been published in journals such as Journal of Management Information Systems, Journal of
Marketing, Journal of the Association for Information Systems, and Information Systems
Journal. He has several years of consulting experience in the areas of IT service management,
digital consumer services, and business analytics.
IVO BLOHM is an Assistant Professor for Data Science and Management at the Institute for
Information Management at the University of St. Gallen. His research focuses on business
analytics, crowdsourcing and crowd work, as well as digital platforms. His work has ap-
peared, amongst others, in journals such as Information Systems Research, Journal of Man-
agement Information Systems, or California Management Review.
Footnote: The authors acknowledge the JMIS Editor-in-Chief and the anonymous reviewers
for their valuable contributions during the review process.
3
Abstract
While many firms in recent years have started to offer public Application Programming Inter-
faces (APIs), firms struggle with shaping digital platform strategies that align API design with
aspired business goals and the demands of external developers. We address the lack of theory
that explains the performance impacts of three API archetypes (professional, mediation, and
open asset services). We couple survey data from 152 API product managers with manually
coded API design classifications. With this data, we conduct cluster and regression analyses
that reveal moderating effects of two value creation strategies (economies of scope in produc-
tion and innovation) on the relationships between API archetype similarity and two API per-
formance outcomes: return on investment and diffusion. We contribute to IS literature by de-
veloping a unifying theory that consolidates different theoretical perspectives on API design,
by extending current knowledge on the performance effects of API design, and by empirically
studying the distinct circumstances under which digital platforms facilitate economies of
scope in production or in innovation. Our results provide practical implications on how API
providers can align API archetype choice with the value creation strategy and the API’s busi-
ness objective.
Keywords and phrases: application programming interface, boundary resource, digital plat-
form, economies of scope, cluster analysis, survey research
4
Introduction
The growing number of publicly available Application Programming Interfaces (APIs) sug-
gests that offering APIs today has become a common instrument of digital strategy [86]. The
API directory ProgrammableWeb reported over 22,500 registered APIs in October 2019 and a
five-year consecutive growth rate of over 10% [86]. By now, successfully designed and man-
aged APIs outperform traditional modes of service distribution (such as e-commerce web-
sites) at well-known digital service providers such as Expedia, eBay, and Salesforce [51, 74].
The majority of API providers, however, struggles with designing successful APIs,
because a solid technical solution does not suffice; rather, the API must align with the overall
business objectives and the demands of third-party developers and end customers [12]. Con-
sidering that APIs transform entire industries by enabling agile service development, speciali-
zation, scalability, and leveraging network effects [74], many firms overlook the APIs’ signif-
icance for their strategic competitiveness [51]. The misalignment of an API’s design and its
provider’s business objectives may be the consequence. For example, a lot of API providers
adopt transaction-based pricing models [11]. However, establishing two-sided platforms by
means of an API and attracting third-party developers requires paying out commissions to
developers for each transaction as the case of Walgreen’s Photo Prints API demonstrates [3].
Further, many API initiatives fail because of insufficient knowledge about the targeted seg-
ment of third-party developers [11]. Hence, APIs provide insufficient incentives for these
developers or fail to align the API provider’s business interests with those of developers [3].
Lastly, focusing on APIs as a single channel for distributing software solutions may impose
high implementation effort on software adopters [58]. Owing to these challenges, API provid-
ers require knowledge that supports the alignment of API design, their business goals, and the
objectives of third-party developers.
5
The literature on digital platforms broadly considers APIs as boundary resources
through which platform providers execute choices of platform architecture and governance
[22, 38, 100-102]. Our literature synthesis yields three API archetypes with characteristic dif-
ferences regarding the design of a platform’s partitioning, systems integration, decision rights,
control, and pricing. Professional services provide access to cloud-based IT resources, which
providers traditionally distribute as installable software or make accessible via browser-based
interfaces [8, 61, 108]. Mediation services offer access to a two-sided platform’s resources
based on which third-party developers design complementary service offerings for the plat-
form’s end customers [76, 80, 94]. Open asset services give free-of-charge access to organiza-
tion-internal IT resources with low integration effort [48, 56, 65, 85].
We survey 152 API providers and investigate the interaction effects of API design
and two value creation strategies – economies of scope in production and innovation– on API
return on investment (ROI) and diffusion. We apply qualitative content analysis to these APIs
in order to reveal API design choices that may influence API performance. Applying cluster
analysis, we verify the theoretically derived typology of professional, mediation, and open
asset services. We show that one can distinguish these services by distinct API design charac-
teristics. Further, we conduct ordinal logistic and negative binomial regression analyses and
show that API providers that align their APIs’ design with the intended platform-based value
creation mechanism exhibit higher levels of API ROI and diffusion. Specifically, we find that
API providers that follow the archetypical designs of professional or mediation services and
that target economies of scope in production have higher levels of API ROI than others. API
providers that choose an open asset services design and target economies of scope in innova-
tion exhibit higher levels of API diffusion than others.
Our research contributes to closing three research gaps in the digital platforms litera-
ture. First, prior literature on API design is scattered and studies API design in disparate and
6
isolated contexts. One group of authors considers APIs as distribution channels for cloud-
based professional services [8, 25, 41, 108]. A second group studies APIs as boundary re-
sources to multi-sided platforms [27, 37, 38, 76, 80]. A third group analyzes APIs in the con-
text of open data [48, 56, 65, 85]. Considering the strategic role of APIs for platform provid-
ers [9] and that this disparate literature insufficiently explains how the breadth of possible API
design choices relating to platform architecture and governance affects strategic API out-
comes, Yoo et al. [110] call for a generalizable theory that explains API design choices and
strategic consequences. Addressing this call, we provide a unifying perspective on the design
of three API archetypes that explains API design and strategic API outcomes across these
distinct literature streams. It is grounded in contemporary literature on platform architecture
and governance [100, 102] and synthesizes prior API literature.
Second, prior API research does not study the design and outcomes of individual
APIs but looks at an aggregate level at the set of APIs offered by a firm [9] and by a platform
[7, 95, 101, 109]. These studies only allow limited implications on the design and perfor-
mance effects at the level of individual APIs. They focus on a firm’s or platform’s general use
of potentially multiple APIs and do not establish a direct relationship between the design of
individual APIs and API performance. By choosing the API as unit of analysis, we provide
novel theory regarding the distinct consequences of API-level design choices on API perfor-
mance in terms of API ROI and diffusion.
Third, prior literature provides disconnected theories of how platforms facilitate val-
ue creation in platform-based ecosystems [35]. Some authors theorize on platform-based
economies of scope in production [e.g., 55, 72]. Other authors focus on economies of scope in
innovation [e.g., 1, 75]. An integrating theory that explains how APIs facilitate either or both
value creation mechanisms is currently missing. Adopting a conceptualization that “sees plat-
7
forms through an organizational lens” [35, p. 1240], we integrate these two perspectives and
study simultaneously how APIs facilitate economies of scope in production and innovation.
In summary, our research addresses the lack of theory that interrelates different API
design choices, platform-based value creation mechanisms, and API-level performance. We
develop a theoretical model that proposes how the interaction of API design with a platform
provider’s targeted value creation mechanism affects an API’s ROI and diffusion. This paper
proceeds as follows. In the theoretical foundations, we discuss prior research on digital plat-
forms and APIs. Subsequently, we develop our hypotheses in the theory development section.
We then present our research methodology and estimation approach, followed by the results
section. After a discussion of the contributions, we end with limitations and potential avenues
for future research.
Theoretical Foundations
We define APIs as machine-readable interfaces that connect multiple applications, govern
application interaction, and remove the need to know the inner workings of how an API’s
functionality is provided [53]. While APIs may also regulate the communication on local ma-
chines, this study focuses on web services that provide remote access over the Internet [20].
We focus our analysis on the large API subgroup of public APIs that are accessible from out-
side of a company’s network [53, 86]. API providers openly communicate the specification of
public APIs in order to promote APIs to the community of third-party developers. In the next
subsections, we discuss how API design relates to the architecture and governance of digital
platforms and prior research on API archetypes.
Architecture and Governance of Digital Platforms
APIs represent boundary resources of digital platforms [22, 38]. Boundary resources are soft-
ware tools that transfer design capability to developers [105] and allow platform owners to
control the ecosystem that is formed by third-party developers [38]. Hence, boundary re-
8
sources are regulations that control the arm’s-length relationship between a platform owner
and application developers [38]. From a technological perspective, digital platforms consist of
an extensible codebase for a core functionality that is shared by connected modules and inter-
faces such as APIs. Modules are software subsystems, i.e., applications that third-party devel-
opers provide and that add functionality to the platform. APIs support the interoperation be-
tween platform core and modules [102]. One can distinguish platforms by design choices re-
lated to platform architecture and governance [100-102], which are executed through bounda-
ry resources such as APIs [22, 38, 87]. The information systems literature discusses several
aspects related to API design (API characteristics) that have an impact on platform architec-
ture and governance, which we summarize in Table 1 and discuss in the following.
- Table 1 about here -
Architecture has two main functions: (1) partitioning and (2) systems integration
[100]. (1) Partitioning refers to how platform-based functions are decomposed into relatively
autonomous subsystems, i.e., modules. A trait of partitioning is platform span, i.e., the num-
ber of modules that is determined by the level of functional disaggregation [91]. The scope of
functionalities that a platform owner exposes via APIs is characteristic for the platform [7].
The API literature distinguishes between decomposition at the architectural level of applica-
tion functionality or even finer disaggregation at the level of data or infrastructure access
[110]. Accordingly, API functionality refers to providing complex information processing
capabilities [109], i.e., executing business processes [112], in contrast to making accessible
lower-level resources, i.e., data- and infrastructure-as-a-service [25, 46]. Partitioning not only
applies to an API’s level of functional disaggregation, but also relates to the distribution of
end customer-oriented functionality. APIs can be designed as a distribution channel that con-
nects third-party developers with an API provider’s end customers [93]. APIs then provide
end customer access that allows developers to exploit platform-based marketing resources
9
[88] and to offer value-added services to the platform’s installed end customer base [60]. (2)
Systems integration refers to how a platform provider interconnects with external developers.
It is common to extend a software product by offering an API as an alternative access channel
[77], because offering APIs facilitates the integration into customers’ systems landscapes
[61]. We refer to such an API access to services that providers complementarily distribute as
software products or via websites as multi-channel access. Further, APIs can allow secure
communication by using message encryption standards [42]. Security risks, e.g., data leakage,
are among the most important barriers for adopting professional services [63]. The API trait
security thus characterizes an API provider’s investments into function assurance by imple-
menting encryption mechanisms.
Platform governance addresses (1) the allocation of decision rights, (2) the
execution of control, and (3) a platform’s pricing policies [100]. The (1) decision right to
maintain the end customer relationship is a strategic component [93]. A platform owner can
either keep this right or leave this to the external developer. API providers that keep the end
customer relationship can steer API developers towards implementing services that are
complementary to the API providers’ end customer-facing offerings [9]. APIs then position
third-party modules to fill holes in the API provider’s product line [37] or to innovate value-
adding functionality to an API providers’ platform [102]. (2) Regarding the execution of
platform control, the process of granting permission for an activity represents a functional
component in API specifications [42]. Since APIs allow access to proprietary resources, API
providers must protect their strategic assets and – at the same time – encourage developer
innovation [102]. Authorization allows API providers to execute control [9]. Alternatively,
API providers may go without authorization in order to decrease adoption barriers, e.g., in the
case of open data [65]. (3) API providers execute platform pricing via two API features. APIs
can serve as a direct source of revenue via charging [112]. Charging strategies may include
10
transaction-based and subscription-based charges [77]. Alternatively, providers may offer
API access free-of-charge and aim at non-monetary benefits [29]. Further, API providers can
use revenue sharing to attract API developers with the goal to enrich an API provider’s
product offerings [54]. For example, the appropriation of value between providers and
developers through revenue sharing represents a key success factor for offering a wide
portfolio of services in mobile ecosystems [78, 80].
Typology of Public APIs
A synthesis of API literature (see Online Appendix A) suggests that API providers offer three
distinct services and that each of these API archetypes incorporates distinct API characteris-
tics related to the design of API architecture and governance. We define these archetypes in
Table 2.
- Table 2 about here -
Professional services offer infrastructure-, platform-, data-, or software-as-a-service.
Via standardized interfaces, they facilitate the consumption of the API provider’s modularized
offerings [8, 108]. For example, mobile network operators offer APIs that provide paid access
to the telecommunication network’s functionalities such as telephony [41]. Professional ser-
vices represent alternative channels to browser-based or off-the-shelve software offerings. For
example, with the Cloud Datastore service, Google offers data-as-a-service via a browser-
based editor and, alternatively, via the Cloud Datastore API [25]. Professional service provid-
ers generate direct revenue streams by charging for API consumption [29, 61, 77].
Mediation services expose platform resources to third-party developers, upon which
third-party developers innovate end customer-facing services that are complementary to the
platform’s end customer-oriented offerings [94]. Mediation services provide, among others,
business development, marketing, and resource bundling [88]. Providers of mediation services
offer incentives in order to subsidize third-party innovation. The Android API, for example,
11
includes free API access to Google’s Android platform and is supplemented with revenue-
sharing mechanisms via the Google Play store [80].
Open asset services provide free-of-charge access to proprietary IT assets of a com-
pany [36, 48, 56]. Such offerings include open access to data [48, 65], to infrastructure, or to
applications [36]. While researchers usually discuss open asset services in non-commercial
contexts [56, 64], profit-oriented companies may equally offer such services [48]. Open asset
services encourage a provider’s interaction with the external developer community [64]. This
is because offering free access to company-internal assets, removing technological access
barriers such as user authentication restrictions, and providing generative and easy-to-
integrate IT resources lowers the adoption barriers for external developers [85]. Further, the
use of standardized interfaces and well-defined governance approaches establishes trust be-
tween the API provider and external developers [36]. The Github API, for example, offers
free programmatical access to the version control system’s functionalities such as forking
projects, sending pull requests, and monitoring development [73].
Theory Development
We adopt Gawer’s [35] organization-centric conceptualization of digital platforms as meta-
organizations. This conceptualization emphasizes a technological platform’s capacity to host
inter-organizational service ecosystems [80]. In such platform-based ecosystems, value-
adding activities of resource integration are provided by multiple actors and customers [67].
We distinguish two mechanisms of value creation in digital platforms discussed by Gawer
[35] that are rooted in cost reductions owing to the joint value creation of platform partici-
pants in comparison to creating value separately: economies of scope in production and in
innovation. We propose that value creation mechanisms in digital platforms and API design
are interlinked, i.e., we assume that distinct API archetypes fit different value creation mecha-
nisms and target varying objectives. We depict the research model in Figure 1.
12
- Figure 1 about here -
API Return on Investment, Diffusion, and Value Creation Mechanisms
API providers may follow two different objectives by offering APIs that are related to two
major types of business objectives, value generation and value appropriation [70]. They may
aim at achieving a positive ROI by creating revenue streams (relating to value appropriation)
and at reaching a high API diffusion level, which may stimulate innovation (relating to value
generation) [38, 87]. ROI is commonly used to assess a new product’s performance [50]. Re-
turn on API investment describes the ratio between net profit and costs resulting from invest-
ing in API development and operations. Many APIs directly target a positive ROI by charging
for API consumption [61, 77] or by generating indirect revenue streams through an increased
attractiveness of a core product [47]. The diffusion of a service generally includes awareness
and adoption among potential customers [89]. API awareness characterizes the extent to
which external developers gain information about the API and its attributes. Adoption entails
the usage of an API by third-party developers. API diffusion provides non-monetary benefits
to API providers [29] and enhances the provider’s internal innovation capacities [16].
According to the contingency perspective of organizational strategy, there is no uni-
versally superior strategy, irrespective of the environmental or organizational context [104].
Companies must, therefore, align their internally oriented resource development with their
externally oriented strategy [40]. We follow this notion and argue that a provider’s internal
design of boundary resources (specifically API design) must match its externally oriented
ecosystem positioning (specifically the targeted mechanisms of inter-organizational value
creation) in order to achieve positive outcomes. Inter-organizational value creation in plat-
form-based ecosystems has its roots in different economies of scope [35], which we refer to as
value creation mechanisms. In the following, we develop a fit-as-moderation perspective by
conceptualizing the match between internal resources and the externally oriented strategy in a
13
moderation model [104]. The fit-as-moderation approach suggests that the interaction be-
tween the predictor and the moderator “is the primary determinant of the criterion variable.“
[104, p. 424]. Specifically, we propose that the interaction of an API’s similarity to archetypi-
cal API designs and the levels to which API providers target value creation mechanisms af-
fects API ROI and diffusion. Table 3 provides an overview of the constructs and definitions
of our research model.
- Table 3 about here -
Economies of Scope in Production
Economies of scope in production is a phenomenon in which the joint production of a product
is less costly than producing the intermediate and the end product separately [79]. If two suc-
cessive value creation stages are interlinked, vertically integrating these stages may allow for
jointly optimized production [21, 34].
Targeting economies of scope in production owing to vertical integration leverages
an API’s ROI for the professional service archetype, because professional services aim at fa-
cilitating the integration of the service provider’s offerings into the API developers’ applica-
tions [8, 108]. The modularization of IT infrastructure allows for reusing IT assets in a flexi-
ble manner [71] in inter-organizational service relationships, which is particularly valuable for
service customers with highly customized and complex application landscapes [108]. The use
of standardized interfaces facilitates the service integration in the course of customer’s appli-
cation development projects, because software developers require less effort to familiarize
with the service’s functionality and syntax [63]. The professional service’s flexibility and in-
tegrability ultimately increase the attractiveness of a service provider’s offerings. By creating
novel revenue streams via direct or indirect charging mechanisms, while requiring relatively
low investments, professional services implement a value appropriation mechanism and thus
directly contribute to an API’s ROI. An exemplary professional service is Salesforce’s Analyt-
14
ics API. Salesforce traditionally is a browser-based software-as-a-service provider for CRM
solutions. Salesforce’s Analytics API allows programmatic access to analytics features such as
datasets and dashboards [2]. This API offers easy integrability into customer application land-
scapes and clearly communicated service-level agreements. It is bound to a subscription of
Salesforce’s cloud product.
In contrast to open asset services, that are offered free-of-charge and focus on value
generation by spurring innovation via diffusion in the open development community [48],
professional services include charging mechanisms and do not target wide accessibility
among the external developer community, i.e., API diffusion. From the above argumentation,
we conclude that there is a fit between an API’s similarity to the professional service arche-
type and the target level of economies of scope in production with respect to achieving API
ROI.
H1: The interaction of an API’s similarity to the professional service archetype and
the target level of economies of scope in production is positively related to API re-
turn on investment.
Targeting economies of scope in production owing to vertical integration may further
leverage API ROI for the mediation service archetype because this archetype is geared to-
wards facilitating the integration of business development and marketing resources into third-
party developers’ applications [88]. Platform providers, by offering mediation services, aim to
generate novel or increased revenue streams with relatively low additional investments and
thus target an increased ROI [81]. Mediation services are frequently provided to third-party
developers free-of-charge, but with the goal to generate end customer revenues [94]. Com-
pared to alternative boundary resources (such as browser-based user interfaces) that platform
providers frequently offer [38], API-based mediation services allow easy integrability into
third-party applications and thus increase a platform’s overall attractiveness to application
15
developers. This, in combination with a platform’s value appropriation mechanisms, such as
collecting end customer fees or charges for targeted advertising, results in an increased ROI.
Dropbox, for example, offers the Dropbox API which exposes standardized file management
capabilities to third parties. Service providers, such as streamboxr, integrate with Dropbox’s
API and thus free end customers from having to conduct file integration manually [19]. Third-
party developers contribute to improving Dropbox’s end customer-facing offerings. Higher
end customer revenues lead to an increased ROI of the Dropbox API [23]. Consequently, we
conclude that there is a fit between an API’s similarity to the mediation service archetype and
the target level of economies of scope in production with respect to achieving API ROI.
H2: The interaction of an API’s similarity to the mediation service archetype and the
target level of economies of scope in production is positively related to API return on
investment.
Economies of Scope in Innovation
Economies of scope in innovation occur when jointly innovating on two products is cheaper
than developing independent innovations on these two products [35, 75]. Innovating firms
share IT resources in the presence of innovational complementarities that emerge in business-
to-business relationships when a firm’s innovation increases the productivity of customers’
research and development investments [14].
Targeting economies of scope in innovation leverages the diffusion of open asset
services because open asset services are geared towards stimulating generativity by providing
free-of-charge access to core platform modules [38]. Generativity refers to the “capacity to
produce unprompted change driven by large, varied, and uncoordinated audiences” [113, p.
1980]. Modularity spurs third parties’ innovativeness through experimentation [38, 75, 95].
Providing open asset services attracts external innovators, because of the low financial cost
and developmental effort that innovators require to establish and maintain interoperability
16
[56, 101]. The open asset service’s generativity and modularity ultimately lead to API diffu-
sion. Open asset services, in contrast to professional services, do not target ROI, because they
focus on exploring novel modes of value generation through involving third-party developers
rather than on value appropriation [16]. The New York Times Article Search API, for example,
allows free search of articles from 1981 to today and returns headlines, abstracts, lead para-
graphs, links to associated multimedia, and other article metadata [99]. This API, by attracting
large interest in the open development community, has led to the development of diverse
mashups, which may also stimulate innovations in the New York Times’ offerings. Hence, we
conclude that there is a fit between an API’s similarity to the open asset service archetype and
the target level of economies of scope in innovation with respect to achieving API diffusion.
H3: The interaction of an API’s similarity to the open asset service archetype and
the target level of economies of scope in innovation is positively related to API diffu-
sion.
Targeting economies of scope in innovation may leverage API diffusion for media-
tion services because these services are geared towards facilitating open access to resources
that link external developers to the platform’s end customers [88]. Exposing platform re-
sources through mediation services may trigger third-party developer innovations of end cus-
tomer-facing services that go beyond the API provider’s scope of imagination [24, 80, 97].
Platform providers, by offering mediation services, leverage economies of scope in innovation
to broaden the scope of functionality offered by the platform [39]. Mediation services, to in-
centivize API diffusion, may involve the distribution of end customer revenues among the
platform and third-party developers via revenue sharing mechanisms [81]. Innovating novel
value propositions is important for attracting user crowds independent of the simultaneous
implementation of value appropriation mechanisms [16]. Platforms may even focus on diffu-
sion prior to implementing value appropriation mechanisms in later stages, because appropri-
17
ating value may conflict attracting platform users [52]. The YouTube Data API, for example,
is a mediation service that allows content providers to freely upload, update, and delete videos
on the end-customer-facing YouTube platform. With this API, YouTube focused on attracting
a large mass of content providers in an initial stage of the YouTube platform’s lifecycle and
added value capture mechanisms (such as targeted advertising) in a later stage [16]. Thus, we
conclude that there is a fit between an API’s similarity to the mediation service archetype and
the target level of economies of scope in innovation with respect to achieving API diffusion.
H4: The interaction of an API’s similarity to the mediation service archetype and the
target level of economies of scope in innovation is positively related to API diffusion.
Research Methodology and Estimation Approach
We triangulate quantitative and qualitative data collection and analysis methods in order to
investigate the interrelated effects of API design and targeted economies of scope on API ROI
and diffusion across professional, mediation, and open asset services. First, we surveyed
product managers at API providers that are listed in the Internet’s most complete public API
directory ProgrammableWeb [29, 86, 111] in order to collect data on the API providers’ tar-
geted value creation mechanisms as well as on API ROI. Second, we collected secondary data
regarding the actual diffusion of these APIs among developers. Third, we applied qualitative
content analysis to the documentations of APIs on which we gathered survey and secondary
data. This analysis allowed us to collect data on the specific API designs that API providers
have implemented. In terms of data analysis, we combine cluster and regression analyses. We
first apply cluster analysis to the data from our content analysis in order to verify our typology
of theoretically derived API archetypes and to develop a more fine-grained understanding of
their dominant design characteristics. Second, we investigate the differential effects of econ-
omies of scope in production and innovation on API diffusion and ROI for the three arche-
types of API design by applying ordinal logistic and negative binomial regression.
18
Data Sources and Variables
Survey Research: Value Creation Mechanisms, API Return on Investment, and Controls
We conducted a cross-sectional survey to collect complete response data from 185 product
managers who represent different API providers. The survey was online from May to July
2017 and targeted API product managers at for-profit API providers that were responsible for
the design of the APIs, the strategies pursued with the APIs, and the overall API operations.
We mailed the survey to 2950 organizations that were listed on ProgrammableWeb. The re-
sponse rate of our survey was 6.17%, which is comparable to similar studies that use non-
personalized mailings [92]. In order to motivate respondents to participate, we provided ac-
cess to an API industry study that reported preliminary results of our project. We sent two
reminder e-mails to improve response rates. We considered 152 responses from for-profit API
providers for our study. Even though we explicitly targeted for-profit API providers, we could
not verify profit orientation for the other responses in our qualitative API analysis. In order to
ensure relevance and generalizability of our results, we targeted a broad range of different
industries. The API providers mainly offered services in regard to IT & Communication
(41%), Education & Science (14%), Marketing & Media (10%), Wholesale & Retail (7%), or
Leisure (5%). Most API providers resided in the USA (38%), Germany (12%), UK (9%),
Switzerland (7%), and France (5%).
We undertook various measures for mitigating the risk of common method variance
that is related to our survey-based measurement of value creation mechanisms and API finan-
cial performance [82]. We provided a cover story for our questionnaire to emphasize that the
independent and dependent variables are unconnected. Second, we developed simple struc-
tured questions and avoided ambiguous terms. Finally, we explicitly pointed out in our cover
story that all answers would be anonymous and we would not establish a connection between
answers and individuals. We checked the extent of common method variance by inspecting
19
the correlation matrix (see Appendix D). Common method bias is reflected by extremely high
correlations above 0.9 or below -0.9 . However, in our study, the highest correlations among
our survey variables are -0.24 and 0.41. In sum, these procedural remedies and the results
from our correlation analysis give no indication of potential threats resulting from common
method bias. We also checked for non-response bias [4]. In addition, we checked for differ-
ences in industries or company sizes. We found no significant differences and our data does
not indicate non-response bias. Online Appendix B provides an overview of the survey in-
strument.
As our study focuses on the API-level, we asked the repondents to indicate the API
which they referred to in the survey. This information was then used to collect qualitative and
secondary data about the APIs.
API Return on Investment. Whereas on the firm-level, ROI measures are widely
available, our unique focus on the API level inhibits using objective financial performance
measures. Thus, we followed a long history of measuring profitability of new products in the
new product development literature. Following Cooper [18] and McNally et al. [69], we used
a single-item measure for API ROI that captures the degree to which an API’s ROI meets the
financial goals of the API provider. Such subjective measures of financial performance allow
for a relative comparison of API’s financial performance [69], because they avoid problems in
comparing actual values for different projects and products [17] and allow to account for the
API provider’s specific organizational goals that are associated with the APIs [5]. Further,
such relative measures help to capture the peculiarities of different industries API providers
operate in. Finally, subjective measures have been found to produce equally valid perfor-
mance measurements in a variety of contexts when being compared against objective ones
[26, 106].
20
According to Berquist and Rossiter [10], single-item measurements have similar va-
lidity as multi-item scales when the construct being measured is doubly concrete in the mind
of the respondent. This means that both the object of the study (i.e., the respondent’s API pro-
vider) as well as its attribute (i.e., its financial performance) are concrete such that they can be
easily and uniformly imagined [84]. By contrast, constructs consisting of formed or abstract
objects (e.g., all API providers in a given industry) and attributes (e.g., service quality or mar-
ket orientation) would require a multi-item measurement. As our measure of API ROI reflects
an overall assessment of financial performance, it can be considered as being concrete [84].
The same is true for the respondents’ API provider. Thus, we consider our subjective single-
item measure as being valid for our purpose.
Value Creation Mechanisms. Owing to the lack of survey-based measurements of
Gawer’s [35] platform value creation mechanisms, we introduce self-developed measure-
ments that capture the extends to which economies of scale in production and innovation de-
scribe a company’s API strategy. The measure for economies of scope in production compris-
es three five-level Likert items that characterize the level to which an API facilitates the flexi-
ble integration, adaptation, and deep integration of IT resources. The items are inspired by
D'Aveni and Ravenscraft [21], Garcia et al. [34], and Gawer [35]. The instrument for econo-
mies of scope in innovation consists of three items that describe the extent to which APIs al-
low to tap the inventive capacities of the external developer community, to exploit the crea-
tive potential of external developers, and to enhance an API provider’s innovation capabili-
ties. This instrument is informed by Bresnahan and Trajtenberg [14], Gawer [35], and
Nambisan and Sawhney [75].
Controls. We included two API-level controls. We proxied the API’s quality of im-
plementation by capturing the functional quality and service innovativeness of the API. Func-
tional quality captures the degree to which an API offers unique features compared to, is
21
clearly superior to, and is of higher quality than competing APIs [98]. Service innovativeness
captures the degree to which an API is innovative in the specific industry of the API provider
[30]. The API provider-level control number of employees accounts for organizations of dif-
ferent size, as an API might be more central for the overall business model of smaller organi-
zations than larger organizations. We further included two respondent-level controls. The re-
spondent’s years with the API provider and affiliation may potentially bias response behavior
[82].
Content Analysis and Cluster Analysis: Similarity to API Design Archetypes
Following a fit-as-moderation perspective, we propose that APIs with different design traits
require distinct value creation strategies. While we collected data on value creation strategies
by applying survey research, we followed a different approach for investigating API design.
First, we applied content analysis to the API websites and related information in order to col-
lect data on API’s specific design characteristics. Then, we applied cluster analysis to this
data in order to reveal API design archetypes and verify the three theoretically derived API
designs – professional, open asset, and mediation services. Finally, we measured the degree to
which each API’s design followed these archetypes by measuring their similarity to these de-
sign archetypes.
API Designs Characteristics. In order to collect data on the specific API designs, we
applied content analysis to the corresponding API websites, the APIs’ technical
documentation, as well as their terms of use. Based on the nine API design characteristics in
Table 1, we developed a coding scheme that comprised definitions of the API design charac-
teristics, respective binary indicators (for existence and non-existence of an API characteris-
tic), and coding examples. Using this coding scheme, we content analyzed all 152 APIs for
which respondents returned a complete questionnaire. In order to ensure the reliability, two
independent researchers coded all APIs. Using a coding template, the researchers had to pro-
22
vide evidence for why they have coded an API design characteristic in a certain way. The two
researchers reached a Cohen’s Kappa of 0.82, which indicates excellent agreement [57].
Based on the coding templates, the coders discussed and resolved coding differences resulting
in nine dichotomous variables per API. These variables indicate whether a certain API design
characteristic has been implemented by an API provider or not (0 = no implementation, 1 =
implementation).
API Design Archetypes. We identify archetypes of API design as cluster centroids
by applying cluster analysis to the nine dichotomous API design characteristics. Cluster anal-
ysis groups entities such that the in-group variation is small in relation to inter-group variation
[68]. By defining distinctive variables (i.e., API design characteristics), cluster analysis
groups entities (i.e., APIs) according to their reciprocal similarities describing natural groups
[62]. In order to avoid idiosyncratic errors specific to a certain clustering technique, we used
different cluster algorithms applying distinct distance metrics. As the primary goal of the clus-
ter analysis was to identify archetypes of API design, we used four different partitioning clus-
tering approaches that create cluster centroids (i.e., average representatives for each cluster)
that we conceptualize as archetypes. We used Spherical K-Means using Cosine distance [49],
a numeric optimization approach using Jaccard distance [62], as well as K-Medians [62] and
Partitioning Around Medoids [83] using Hamming distance. The idea of such algorithms is to
randomly assign entities to a pre-defined number of clusters (k) and then reassign entities iter-
atively to the centroids of these clusters. All these clustering approaches and distance
measures are apt for dichotomous data. Determining an appropriate number of clusters, we
used the Dunn-Index and Average Silhouette Values that measure the compactness of clusters
while also taking into account their separation.
Similarity to API Design Archetypes. Finally, we measured the similarity of each
API to the identified cluster centroids (i.e., API archetypes) for each clustering algorithm: (1)
23
We determined the archetypical design for each cluster (i.e., the average representative). (2)
We calculated the distance between each API and these archetypical implementations using
the distance measures that were used for the clustering (e.g., for the Spherical K-Means clus-
tering using Cosine distance, we used Cosine distance). (3) We transformed the obtained dis-
tance measures to similarity measures in order to increase the interpretability of our results.
We scaled each distance measure by dividing it by its maximum value so that it ranges be-
tween 0 and 1. Then, we subtracted these scaled distance measures from 1.
Secondary Data: API Diffusion
We follow Setia et al. [89] who conceptualize diffusion of open source software as awareness
and adoption among developers. We collected data on API diffusion in three major developer
communities – Github, Stack Overflow, and ProgrammableWeb. For adoption, we collected
the number of publicly available software repositories that use the API and that were upload-
ed by third-party developers on Github. For measuring awareness, we retrieved the number of
API-related comments within Stack Overflow as well as the number of followers of a given
API on ProgrammableWeb. All these data were retrieved using the search mechanism provid-
ed by these communities using the API title and “API” as search terms, e.g., “clickmeter
API”, in December 2018. These measures provide an objective measure of API diffusion and
are apt for dealing with APIs in commercial and non-commercial settings.
Results
Construct Validation
In order to confirm validity and reliability of our survey-based measures, we applied explora-
tory and confirmatory factor analysis. The Measure of Sampling Adequacy was 0.75, indicat-
ing good applicability of exploratory factor analysis. We used the latent root criterion (Eigen-
values >1) for extracting five factors that could be clearly interpreted. Alphas of at least 0.79
suggest good reliability of factors. Composite Reliabilities (CR) exceeded values of 0.5 and
24
the Average Variance Explained (AVE) for each factor surpassed 0.5. Thus, convergent valid-
ity could be assumed [6]. The discriminant validity was checked by using the Fornell-Larcker
criterion, which claims that a factor’s AVE should be higher than its squared correlation with
every other factor [32]. Thus, discriminant validity could be assumed. Construct validation
results are shown in Appendix C.
Our three items measuring API diffusion represent count data. Standard techniques to factor
analysis do not deal well with the discrete, non-negative nature of count data and might lead
to biased results [107]. In order to extract an overarching API diffusion measure, we applied
non-negative matrix factorization to our three API diffusion items. Non-negative matrix fac-
torization is frequently applied to extract latent factors from count data [59, 90]. We followed
Brunet et al. [15] and extracted one latent API diffusion factor that accounted for 62.7% of the
three original item’s variances. We successfully validated the appropriateness of extracting a
single API diffusion factor following the ideas of Frigyesi and Höglund [33].
1
We made sure
that our results are robust regarding other approaches to non-negative matrix factorization
algorithms. Appendix D depicts means, standard deviations, minimum, and maximum values,
as well as correlations of our variables. In all subsequent analyses, we used obtained factor
scores as well as z-standardized scores.
Validation of API Archetypes
Average Silhouette Values and Davies-Bouldin-Indices indicate a robust three cluster solution
(see Appendices E and F). Appendix G exhibits that all clustering approaches produce simi-
1
The basic idea of Frigyesi and Höglund [33] is to investigate how well an extracted factor or a number of extracted factors
can reproduce the initial items from which the factor(s) were formed. They suggest to calculate the residual errors for an
increasing number of factors for a data set and a permuted version of that data set. If the residual errors calculated from the
permuted data set have the same size as the residual errors from the original data set, non-negative matrix factorization has
captured all the “noise” within a data set such that the extracted factor(s) do not contain useful information. However, the
factors in the original data set show considerably smaller residual errors than the factors extracted from the permuted data set.
Differences are biggest for one single factor such that we conclude that this single factor captures the relevant information
from the underlying items.
25
lar results, i.e., there is an average agreement of 92.3% between the different clusterings. This
agreement is backed by a contingency analysis. All χ2 tests are statistically significant (p <
0.01) and an average Cramer V of 0.87 indicates a very high correlation between the nominal
clusterings. We report results for the Spherical K-Means clustering using Cosine distance on-
ly. Based on our theoretical considerations, the implementation of API design characteristics
reflects a conscious design decision of an API provider. Following this line of reasoning, Co-
sine distance is an asymmetrical distance measure and, thus, takes into account such con-
scious design decisions only [31]. By contrast, other applicable distance measures also take
into account non-implemented API design characteristics for which we cannot infer conscious
design. After validating the cluster structure, we report frequency distributions to characterize
the API clusters (see Table 4). We calculate Cramer Vs to test whether or not the API design
characteristics significantly differ across the three clusters. We analyze global differences
across all clusters and apply posthoc tests, comparing single clusters. In order to ensure that
the analysis represents a realistic picture of API design characteristics, the assignment of APIs
was manually verified for plausibility. We report cluster centroids (i.e. the API characteris-
tics’ values for the three archetypes) and archetypical examples in Table 5.
- Table 4 and Table 5 about here –
Professional Services: APIs in the professional services cluster are characterized by a
high probability of offering sophisticated information processing functionalities that go be-
yond the simple provision of data and for which API providers request transaction- and sub-
scription-based charges. User authorization and security measures are also quite strongly as-
sociated with this cluster. This cluster can be well matched to the group of professional ser-
vices [8, 61, 108]. Choosing the professional service archetype, API providers create an API
that enables their clients to integrate the functionality of the API provider’s offerings directly
into the client’s existing information systems and the evolving business operations. These
26
APIs are frequently built to leverage an already existing service or product of the API provid-
er for which the API usually represents an alternative access channel. With a share of 67%,
the professional service cluster is the biggest API cluster. As an archetypical example,
Salesforce’s Analytics API offers programmatic access to analytics features [2].
Mediation Services: APIs in the second cluster are characterized by providing devel-
opers access to end customers; the provider of a mediation service, however, entertains its
own direct relationship with these end customers. APIs in this cluster most frequently engage
in revenue sharing approaches and make strong use of user authorization. As for professional
services, API providers offer a broad range of functionalities that go beyond infrastructure
and data access. Given these characteristics, this cluster matches well with the mediation ser-
vice [76, 80, 94]. Based on extant information processing functionalities that mediation ser-
vices provide, API developers can develop new service offerings for the API providers’ end
customers. This API cluster accounts for 18% in our sample. The Dropbox API, as an arche-
typical mediation service, allows app developers programmatic access to file synchronization
and storage functionalities [23]. Dropbox provides marketing for apps that integrate with the
Dropbox API on its website and requires app customers to have their own Dropbox subscrip-
tion.
Open asset services: APIs in the third cluster are characterized by providing multi-
channel access to IT infrastructure or data resources, i.e., the API reflects an alternative access
option. API providers apply neither transaction-, nor subscription-based charges. Also, they
offer no revenue sharing options. Further, they show the lowest usage of user authorization
and security options. Given these traits, APIs in this archetype match well open asset ser-
vices[48, 56, 65, 85]. With low access barriers and their high versatility, such APIs are in-
tended to involve the general public in approaches to open innovation. This API cluster ac-
counts for 15% of all surveyed API providers. The New York Times Article Search API is an
27
archetypical open asset service that offers free access to article data and metadata that is also
available via the New York Times website [99].
Hypothesis Test
In order to test our hypothesis, we again present results that are based on the Spherical K-
Means clustering only. However, results are very consistent between the different clustering
approaches. API ROI reflects a single item that has been measured with a five-point Likert
scale. Thus, API ROI can be best described as being of ordinal nature such that ordinal lo-
gistic regression is an appropriate modeling choice [13, 43, 45]. Similarly, we apply negative
binomial regression in order to account for the fact that the API diffusion measure relies on
count data.
We first test our API ROI hypotheses (H1 and H2). Ordinal logistic regression is a
generalization of binary logistic regression and can accommodate dependent variables that
consist of more than two ordinal levels by applying a cumulative logit model. A central pre-
requisite of ordinal logistic regression is the proportional odds (also known as parallel regres-
sion) assumption that claims that the relationship between each pair of outcome categories of
the dependent variable is the same [43]. We applied Brant’s [13] test in order to test this as-
sumption. We yielded non-significant test statistics indicating that proportional odds can be
assumed. We estimated the following regression:
Model 1:
αβ with
α + β1 Economies of Scope in Production + β2 Similarity Mediation Arche-
type
+ β3 Similarity Professional Service Archetype
+ β4 Economies of Scope in Production x Similarity Mediation Archetype
+ β5 Economies of Scope in Production x Similarity Professional Service Archetype
+ β6 Functional Quality + β7 Service Innovativeness + β8 Employees API Provider
+ β9 Respondent Management Level + β10 Respondent Years with API Provider
28
API ROI reflects the level of financial goal attainment (1 = API ROI goals are not
met at all; 5 = API ROI goals are completely met), X the vector of predictor variables, β the
vector of estimated coefficients, α the intercepts, and j the number of ordinal response levels
for API ROI. Consequently, Pr(API ROI ≥ j | X) is the probability that API ROI is higher or
equal to the API ROI level j, conditional on the predictors X. We test model 1 in a step-wise
fashion. We first test for direct main effects excluding the interaction terms (model 1a). Then,
we included the moderation effects in order to test our hypotheses (model 1b). Table 6 shows
the results of the ordinal logistic regressions. Model 1a indicates that we cannot detect any
significant main effect of economies of scope in production and the variables measuring the
similarity to the design archetypes of professional / mediation services. Model 1b reveals pos-
itive interaction effects for economies of scope production and similarity to the professional
service archetype (β = 0.46, p ≤ 0.01) as well as to the mediation archetype (β = 0.39, p ≤
0.05).
A likelihood ratio test reveals that R2 increases significantly (p ≤ 0.01) from 0.25 to
0.30 when comparing the models with (model 1b) and without moderation effects (model 1a).
The log odds (exponentiated beta coefficients) for both interaction effects are > 1, i.e., indicat-
ing that API providers following a mediation or professional service design and targeting
economies of scope in production have a higher API ROI than others. In order to better under-
stand the results of these interaction effects, we evaluate how the predicted probabilities of the
different levels of API ROI change with varying degrees of similarity to the API design arche-
types and economies of scope in production. Table 7 shows that API providers that simulta-
neously target economies of scope in production and follow a professional service or a media-
tion service design have higher probabilities of reaching high to very high levels of attaining
their API ROI goals. For instance, API providers that follow professional service design and
have reported high levels of economies of scope in production have a 68% chance of reaching
29
high to very high level of goal attainment. By contrast, API providers that follow a profes-
sional service design without explicitly targeting economies of scope in production or vice
versa have lower probabilities of reaching the same levels of goal attainment (36% and 39%).
Thus, we find support for our hypotheses 1 and 2.
2
– Table 6 and 7 about here –
Testing our API diffusion hypotheses, we first applied a chi-square test for dispersion
and found our data to be overdispersed with p < 0.01 [45]. We believe that this overdispersion
(conditional variance of API diffusion is greater than its conditional mean) is caused by a dis-
tribution that is found in many online-contexts. Most APIs have a low to moderate diffusion
and a handful of APIs show very high diffusion. In order to deal with this overdispersion, we
tested a variety of alternatives including quasi-poisson, negative binomial, or zero-inflated
regression models [45, 106]. However, likelihood ratio and deviance tests revealed that nega-
tive binomial regression best represents our data such that we have chosen this approach.
Negative binomial regression models are based on log-transforming the conditional expecta-
tion of the dependent variable [97], i.e., API diffusion. In greater detail, we have tested the
following regression:
Model 2:
log(E(API diffusion | X))
= α + β1 Economies of Scope in Innovation + β2 Similarity Open Asset Archetype
+ β3 Similarity Mediation Archetype
+ β4 Economies of Scope in Innovation x Similarity Open Asset Archetype
+ β5 Economies of Scope in Innovation x Similarity Mediation Archetype
+ β6 Functional Quality + β7 Service Innovativeness + β8 Employees API Provider
+ β9 Respondent Management Level + β10 Respondent Years with API Provider + r
2
We also performed a robustness check in which we considered API ROI as interval-scaled data and applied ordinary least
square regressions. Results are consistent and lead to identical implications.
30
API diffusion refers to the value of API diffusions and X to the vector of predictor
variables. Thus, E(API diffusion | X) reflects the expected value of API diffusion given the
predictor variables in the model [96]. Again, we test this equation in a stepwise fashion in
order to disentangle main and interaction effects. In model 2a, we find no main effects of our
API design measures and the targeted level of economies of scope in innovation. Model 2b
shows that the interaction between economies of scope in innovation and similarity to the
open asset archetype is significant (β = 0.45, p < 0.05). This interaction effect significantly
increases R2 from 0.25 (model 2a) to 0.3 (model 2b) with p < 0.01. These results indicate that
neither increasing the similarity to the open asset archetype nor following an economies of
scope in innovation strategy is associated with a significant increase in API diffusion in isola-
tion. The exponentiated beta coefficient for designing APIs according to the open asset arche-
type is 1, i.e., striving towards open asset design alone has no positive or negative effect on
API diffusion. By contrast, the exponentiated beta coefficient for the interaction term of simi-
larity to the open asset design and economies of scope in innovation strategy is 1.57. This
means that API providers that embark on economies of scope in innovation in conjecture with
an open asset design increase the diffusion of their API by 57% when being compared to API
providers that follow an open asset design only. We find no support for the interaction be-
tween economies of scope in innovation and the similarity to the mediation archetype. Thus,
we can support H3, while we have to reject H4.
3
Finally, we probe our moderation analyses through visual representations (Figure 2,
3 and 4). These plots support our fit as moderation perspective showing that an alignment
3
We also performed a robustness test for verifying these results. In greater detail, we applied log transformation to the three
items with an offset of 1 [44] as well as applied exploratory and confirmatory factor analysis. The psychometrical properties
of this latent API diffusion factor were excellent. All three items loaded unambiguously and significantly with p < 0.01 on
that factor. Chronbach α was 0.86, the Average Variance Explained was 0.68, and the Composite Reliability was 0.86. Using
the Fornell-Larcker-Criterion the factor was clearly distinguishable from the other ones. Testing Model 2 by means of ordi-
nary least square regression, we found very consistent results that lead to the identical implications.
31
between API design archetypes and targeted economies of scope leads to superior API ROI
and diffusion.
– Figures 2, 3 and 4 –
Discussion
Our analysis of how a provider’s choice of API archetype interacts with its targeting of plat-
form-based value creation mechanisms in influencing API ROI and diffusion provides support
for the theoretically derived hypothesis that the interaction of targeting economies of scope in
production and an API’s similarity to the professional service archetype is positively related
to API ROI (H1). Second, our results support our theoretical argumentation that the interac-
tion of targeting economies of scope in production and an API’s similarity to the mediation
archetype is also positively related to API ROI (H2). Third, our analysis shows that the inter-
action of targeting economies of scope in innovation and an API’s similarity to the open asset
service archetype is positively related to API diffusion (H3). Our results do not provide sup-
port for the fourth hypothesis that the interaction of targeting economies of scope in innova-
tion and an API’s similarity to the mediation service archetype is positively related to API
diffusion (H4). A strategy that targets economies of innovation, thus, does not suffice for
achieving high diffusion with APIs that are similar to the mediation service archetype.
This finding conforms with prior literature, which suggests that diffusion of mediation ser-
vices requires careful coordination of cross-platform externalities and the execution of plat-
form ignition strategies [28]. External developers will only become aware of and adopt a me-
diation service if it provides access to enough customers that external developers target [94],
if there is complementarity between the API provider’s and the developer’s capabilities [52],
and if there is an adequate level of platform governance [102].
32
Theoretical Contributions
We provide three contributions to the literature on digital platforms. First, we develop a unify-
ing theory that consolidates different theoretical perspectives on API design and strategy. Pri-
or literature on API design is scattered and discusses selective aspects of API design in dis-
parate contexts. Some authors study APIs that provide marketing and distribution capabilities
to third-party developers on two-sided platforms [e.g., 80]. This stream of literature focusses
on an API’s ability to provide end customer access and to spur novel end-customer-facing
value propositions from third parties. It produces theories with limited transferability to APIs
on one-sided platforms that primarily focus on value appropriation. A second group of authors
studies APIs that provide open data services [e.g., 56]. It focusses on an API’s ability to ex-
pose assets to external developers free of charge in order to achieve high API diffusion. The
research results are not applicable to fee-based APIs that do not target API diffusion but API
ROI. A third group of authors considers APIs as distribution channels for cloud-based profes-
sional services [e.g., 8]. This perspective focusses on fee-based offerings to API developers
and excludes indirect value appropriation mechanisms on two-sided markets. Considering that
APIs represent key strategic resources of platform providers that determine a platform’s pros-
perity [9], a generalizable theory on API design is required [110] that integrates the disparate
perspectives on API design and explains the strategic impact of design choices across these
isolated contexts. Our unifying perspective on API design that is grounded in contemporary
literature on platform architecture and governance [100, 102] synthesizes prior API literature.
We differentiate between three API archetypes with archetypal design - professional services,
moderation services and open asset services - and offer a fit-as-moderation perspective on the
applicability of economies of scope in production and innovation to these API archetypes. In
so doing, we respond to Yoo et al.’s [110] call for further research on the strategic role of de-
sign decisions regarding boundary resources for digital platforms.
33
As our second contribution, we choose the individual API as our focal unit of analy-
sis and, thus, extend the knowledge on the performance effects of API design. Prior research
studies the aggregate use of APIs and discovers positive performance effects of API adoption
on the firm level [9] and on the platform level [7, 95, 101, 109]. Thus, prior empirical re-
search studies sets of APIs offered by a firm or by a platform and look at the collective role of
APIs for firm and platform performance, respectively. Firm-level and platform-level analyses
do not allow a direct linkage between individual APIs (particularly API design characteristics)
and their performance impacts. At the firm level, Benzell et al. compare firm performance
(market value, R&D expenditure, data breaches) before and after the first introduction of APIs
[9]. They show that whether or not a firm adopts APIs predicts a substantial increase in a
firm’s market value. At the platform level, Xue et al. [109], for example, study how develop-
er’s adoption of APIs, which are offered by a platform, influences their likelihood to continue
developing new applications for this platform. They examine how the adoption of APIs gen-
erally influences platform performance (in terms of the number of apps hosted by a platform).
Benlian et al. [7], as a second example for a platform-level analysis, regard the scope of func-
tionalities APIs collectively offer as part of their operationalization of platform openness, and
show a positive relationship of platform openness with a platform’s perceived usefulness and
developer satisfaction. Because most platforms offer multiple APIs and alternative boundary
resources such as software development kits, these studies only allow limited implications on
the design and performance effects at the level of individual APIs. We take into account dif-
ferent architecture-related and governance-related design decisions that APIs incorporate and
distinguish between three API archetypes of professional, mediation, and open asset services.
We relate these API archetypes to API ROI and diffusion. Our results extend our knowledge
regarding the distinct consequences of different API-level design choices. We, thus, respond
to de Reuver et al.’s [24] call for further research on platform boundary resources that creates
direct platform design knowledge.
34
As our third contribution, we respond to Gawer’s [35] call for empirical efforts to
validate her proposed organization-theoretic platform perspective. We adopt Gawer’s [35]
organization-theoretic conceptualization of platform-based ecosystems that allows us to em-
pirically study two modes of ecosystem value creation simultaneously: economies of scope in
production and innovation. With our moderation-as-fit-perspective, we establish that the pro-
vider’s API design must match the targeted mechanism of inter-organizational value creation
and the business objective (ROI or API diffusion). Our results suggest that, depending on the
design, APIs facilitate economies of scope in production or innovation. Moreover, the fit of
API design with value creation strategies determines whether value exploration targets (via
API diffusion) or value appropriation targets (via ROI) are achievable.
Practical Implications
Our results generate two practical implications. First, API providers are challenged with over-
looking an API’s relevance for strategic competitiveness [51]. Our results show that API pro-
viders should carefully align API archetype choice with the value creation strategy and the
superordinate business objective. Offering professional services may result in a positive ROI
if they improve a software solution’s integrability. Mediation services may increase direct or
indirect revenues in case they facilitate the integration of platform resources, such as end cus-
tomer marketing capabilities for third-party developers. Open asset services, in contrast to the
other two API archetypes, do not focus on value appropriation but on value generation only.
They may generate high levels of API diffusion if the API provider successfully involves
third-party developers in joint innovation. Second, API providers have difficulties in attract-
ing third-party developers and in defining appropriate approaches to value appropriation [3,
11]. We suggest that API providers should align approaches towards value generation and
appropriation with the value creation strategy. Leveraging economies of scope in production
legitimates transaction-based or subscription-based API pricing. The realization of economies
35
of scope in innovation, on the contrary, is not linked to value appropriation, but is an effective
instrument for attracting third-party developers.
Limitations and Further Research
One should interpret the results cognizant of the following limitations that open up avenues
for further research. First, owing to our focus on public Internet APIs, the results do not apply
to private APIs or non-Internet APIs that local applications expose. Further research may ap-
ply our model to investigate non-Internet APIs in local applications. Second, our study is lim-
ited to APIs offered by for-profit providers. Further research may adapt our research model to
study APIs that non-profit providers such as governmental institutions offer. Third, we do not
study the effects of simultaneously offering more than one API. An avenue for further re-
search is to build on our theory and explore the interaction effects that result from offering
multiple APIs. Fourth, we limit our conceptualization of economies of scope in production to
linkage effects resulting from facilitating the vertical integration of provider and customer
systems. We do not study production economies relating to horizontal bundling and the use of
shared inputs in digital platforms, to which future research may attend. Fifth, apart from
economies of scope in production, this research only studies economies of scope in innova-
tion. Another area for further research is a focal study of mediation services and how API
design aligns with economies of scale in demand, which will require a detailed analysis of
cross-platform externalities. Sixth, our measurement approach is limited in that, while the set
of analyzed API design elements is theoretically motivated, backed by a thorough synopsis of
the available literature, and empirically verified, we do not claim exhaustiveness of API ar-
chetypes. Also, API ROI is the product manager’s perception rather than an objective meas-
ure. Moreover, we analyze the levels to which an API provider targets the value creation
mechanisms and do not provide objective measures for economies of scope in production and
in innovation. Further research may introduce other measurement approaches to extend our
36
findings. Seventh, our cross-sectional analyses only ascertain association, but not the causal
relationships inherent in our theoretical arguments. A fruitful area of further research that may
expand on our results deals with investigating longitudinally how a time-varying API strategy
impacts a provider’s platform evolution.
Conclusion
In spite of the rich literature on digital platforms, there is sparse knowledge on the design of
APIs and on how to successfully align API design with an API provider’s contextual condi-
tions. In this research, we developed and validated a theoretical model that explains how the
choice of API design interacts with the levels to which an API provider targets different value
creation mechanisms and how this interaction affects API ROI and diffusion. We contribute
to the IS literate an overarching theory of API design that unifies prior theoretical perspec-
tives and that extends current knowledge on the performance effects of API design.
References
1. Adner, R.; and Kapoor, R. Value creation in innovation ecosystems: How the structure of technological
interdependence affects firm performance in new technology generations. Strategic Management Journal,
31, 3 (2010), 306-333.
2. Analytics REST API developer guide. Salesforce, 2019, Retrieved 8 October, 2019:
https://developer.salesforce.com/docs/atlas.en-
us.bi_dev_guide_rest.meta/bi_dev_guide_rest/bi_rest_overview.htm.
3. Anuff, E. Almost everyone is doing the API economy wrong. Techcrunch, 2016, Retrieved 8 October,
2019: https://techcrunch.com/2016/03/21/almost-everyone-is-doing-the-api-economy-wrong/.
4. Armstrong, S.T.; and Overton, T.S. Estimating non-response bias in mail surveys. Journal of Marketing
Research, 14, 3 (1977), 396-402.
5. Baer, M.; and Frese, M. Innovation is not enough: Climates for initiative and psychological safety,
process innovations, and firm performance. Journal of Organizational Behavior, 24, 1 (2003), 45-68.
6. Bagozzi, R.P.; and Yi, Y. On the evaluation of structural equatation models. Journal of the Academy of
Marketing Sciences, 16, 1 (1988), 74-94.
7. Benlian, A.; Hilkert, D.; and Hess, T. How open is this platform? The meaning and measurement of
platform openness from the complementors’ perspective. Journal of Information Technology, 30, 3
(2015), 209-228.
8. Benlian, A.; Koufaris, M.; and Hess, T. Service quality in software-as-a-service: Developing the SaaS-
Qual measure and examining its role in usage continuance. Journal of Management Information Systems,
28, 3 (2011), 85-126.
9. Benzell, S.G.; LaGarda, G.; Hersh, J.; and Van Alstyne, M.W. The Paradox of Openness: Exposure vs.
Efficiency of APIs. Boston University, 2019, Retrieved 8 October, 2019:
http://dx.doi.org/10.2139/ssrn.3432591.
10. Bergkvist, L.; and Rossiter, J.R. The predictive validity of multiple-item versus single-item measures of
the same constructs. Journal of Marketing Research, 44, 2 (2007), 175-184.
11. Boyd, M. How to pick the best business models for your APIs. ProgrammableWeb, 2017, Retrieved
October 8, 2019: https://www.programmableweb.com/news/how-to-pick-best-business-models-your-
apis/analysis/2017/09/27.
37
12. Boyd, M. Making API decisions: Are you connecting business and technical interests?
ProgrammableWeb, 2017, Retrieved 8 October, 2019:
https://www.programmableweb.com/news/making-api-decisions-are-you-connecting-business-and-
technical-interests/analysis/2017/09/27.
13. Brant, R. Assessing proportionality in the proportional odds model for ordinal logistic regression.
Biometrics, 46, 4 (1990), 1171-1178.
14. Bresnahan, T.F.; and Trajtenberg, M. General purpose technologies ‘engines of growth’? Journal of
Econometrics, 65, 1 (1995), 83-108.
15. Brunet, J.-P.; Tamayo, P.; Golub, T.R.; and Mesirov, J.P. Metagenes and molecular pattern discovery
using matrix factorization. Proceedings of the National Academy of Sciences, 101, 12 (2004), 4164-4169.
16. Chesbrough, H.W.; and Appleyard, M.M. Open innovation and strategy. California Management Review,
50, 1 (2007), 57-76.
17. Chryssochoidis, G.M.; and Wong, V. Customization of product technology and international new product
success: Mediating effects of new product development and rollout timeliness. Journal of Product
Innovation Management, 17, 4, 268-285.
18. Cooper, R.G. The dimensions of industrial new product success and failure. Journal of Marketing, 43, 3
(1979), 93-103.
19. Create Audio Playlists On Dropbox. Streamboxr, 2019, Retrieved 8 October, 2019:
https://streamboxr.com/.
20. Curbera, F.; Khalaf, R.; Mukhi, N.; Tai, S.; and Weerawarana, S. The next step in web services.
Communications of the ACM, 46, 10 (2003), 29-34.
21. D'Aveni, R.A.; and Ravenscraft, D.J. Economies of integration versus bureaucracy costs: Does vertical
integration improve perfoermance? Academy of Management Journal, 37, 5 (1994), 1167-1206.
22. Dal Bianco, V.; Myllarniemi, V.; Komssi, M.; and Raatikainen, M. The role of platform boundary
resources in software ecosystems: A case study. IEEE/IFIP Conference on Software Architecture,
Washington, DC, USA: IEEE Computer Society 2014, pp. 11-20.
23. DBX platform - Develop apps for 500 million Dropbox users. Dropbox, 2019, Retrieved 8 October, 2019:
https://www.dropbox.com/developers.
24. de Reuver, M.; Sørensen, C.; and Basole, R.C. The digital platform: A research agenda. Journal of
Information Technology, 33, 2 (2017), 124-135.
25. Demirkan, H.; and Delen, D. Leveraging the capabilities of service-oriented decision support systems:
Putting analytics and big data in cloud. Decision Support Systems, 55, 1 (2013), 412-421.
26. Dollinger, M.J.; and Golden, P.A. Interorganizational and collective strategies in small firms:
Environmental effects and performance. Journal of Management, 18, 4 (1992), 695-715.
27. Eaton, B.; Elaluf-Calderwood, S.; Sorensen, C.; and Yoo, Y. Distributed tuning of boundary resources:
The case of Apple's iOS service system. MIS Quarterly, 39, 1 (2015), 217-243.
28. Evans, D.S.; and Schmalensee, R. Matchmakers: The New Economics of Multisided Platforms. Boston,
MA, USA: Harvard Business Review Press, 2016.
29. Evans, P.C.; and Basole, R.C. Revealing the API ecosystem and enterprise strategy via visual analytics.
Communations of the ACM, 59, 2 (2016), 26-28.
30. Fang, E. Customer participation and the trade-off between new product innovativeness and speed to
market. Journal of Marketing, 72, 4 (2008), 90-104.
31. Foreman, J.W. Data Smart: Using Data Science to Transform Information into Insight. Indianoplis, IN,
USA: John Wiley & Sons, 2013.
32. Fornell, C.; and Larcker, D.F. Evaluating structural equation models with unobservable variables and
measurement error. Journal of Marketing Research, 18, 2 (1981), 39-50.
33. Frigyesi, A.; and Höglund, M. Non-negative matrix factorization for the analysis of complex gene
expression data: Identification of clinically relevant tumor subtypes. Cancer Informatics, 6 (2008), 275-
292.
34. Garcia, S.; Moreaux, M.; and Reynaud, A. Measuring economies of vertical integration in network
industries: An application to the water sector. International Journal of Industrial Organization, 25, 4
(2007), 791-820.
35. Gawer, A. Bridging differing perspectives on technological platforms: Toward an integrative framework.
Research Policy, 43, 7 (2014), 1239-1249.
36. Gawer, A.; and Henderson, R. Platform owner entry and innovation in complementary markets: Evidence
from Intel. Journal of Economics & Management Strategy, 16, 1 (2007), 1-34.
37. Ghazawneh, A.; and Henfridsson, O. Micro-strategizing in platform ecosystems: A multiple case study.
International Conference on Information Systems, Shanghai, China: Association for Information Systems,
2011, pp. 1-19.
38. Ghazawneh, A.; and Henfridsson, O. Balancing platform control and external contribution in third-party
development: The boundary resources model. Information Systems Journal, 23, 2 (2013), 173-192.
38
39. Ghazawneh, A.; and Henfridsson, O. A paradigmatic analysis of digital application marketplaces. Journal
of Information Technology, 30, 3 (2015), 198-208.
40. Ginsberg, A.; and Venkatraman, N. Contingency perspectives of organizational strategy: A critical review
of the empirical research. Academy of Management Review, 10, 3 (1985), 421-434.
41. Gonçalves, V.; and Ballon, P. Adding value to the network: Mobile operators’ experiments with
Software-as-a-Service and Platform-as-a-Service models. Telematics and Informatics, 28, 1 (2011), 12-
21.
42. Gosain, S. Realizing the vision for web services: Strategies for dealing with imperfect standards.
Information Systems Frontiers, 9, 1 (2007), 53-67.
43. Gunarathne, P.; Rui, H.; and Seidmann, A. Whose and what social media complaints have happier
resolutions? Evidence from Twitter. Journal of Management Information Systems, 34, 2 (2017), 314-340.
44. Guo, J.; Zhang, W.; Fan, W.; and Li, W. Combining geographical and social influences with deep
learning for personalized point-of-interest recommendation. Journal of Management Information Systems,
35, 4 (2018), 1121-1153.
45. Harrell, F. Regression Modeling Strategies. Cham, Switzerland: Springer, 2015.
46. Hartmann, P.M.; Zaki, M.; Feldmann, N.; and Neely, A. Capturing value from big data - A taxonomy of
data-driven business models used by start-up firms. International Journal of Operations & Production
Management, 36, 10 (2016), 1382-1406.
47. Henfridsson, O.; and Bygstad, B. The generative mechanisms of digital infrastructure evolution. MIS
Quarterly, 37, 3 (2013), 907-931.
48. Hjalmarsson, A.; Juell-Skielse, G.; Ayele, W.Y.; Rudmark, D.; and Johannesson, P. From contest to
market entry: A longitudinal survey of innovation barriers constraining open data service development.
European Conference on Information Systems, Münster, Germany: Association for Information Systems,
2015.
49. Hornik, K.; Feinerer, I.; Kober, M.; and Buchta, C. Spherical k-means clustering. Journal of Statistical
Software, 50, 10 (2012), 1-22.
50. Im, S.; and Workman Jr, J.P. Market orientation, creativity, and new product performance in high-
technology firms. Journal of Marketing, 68, 2 (2004), 114-132.
51. Iyer, B.; and Subramaniam, M. The strategic value of APIs. Harvard Business Review Digital Articles,
2015, Retrieved October 8, 2019: https://hbr.org/2015/01/the-strategic-value-of-apis.
52. Jacobides, M.G.; Cennamo, C.; and Gawer, A. Towards a theory of ecosystems. Strategic Management
Journal, 39, 8 (2018), 2255-2276.
53. Jacobson, D.; Brail, G.; and Woods, D. APIs: A Strategy Guide. Sebastopol, CA, USA: O'Reilly, 2011.
54. Jansen, S.; Brinkkemper, S.; and Finkelstein, A. Business network management as a survival. In, Jansen,
S., Brinkkemper, S., and Finkelstein, A., (eds.), Software Ecosystems: Analyzing and Managing Business
Networks in the Software Industry, Cheltenham, UK: Edward Alger Publishing, 2013, pp. 29-42.
55. Krishnan, V.; and Gupta, S. Appropriateness and impact of platform-based product development.
Management Science, 47, 1 (2001), 52-68.
56. Kuk, G.; and Davies, T. The roles of agency and artifacts in assembling open data complementarities.
International Conference on Information Systems, Shanghai, China: Association for Information Systems,
2011.
57. Landis, J.R.; and Koch, G.G. The measurement of observer agreement for categorical data. Biometrics,
33, 1 (1977), 159-174.
58. Lee, D. The API for absurdity. Techcrunch, 2016, Retrieved 8 October, 2019:
https://techcrunch.com/2016/08/27/the-api-for-absurdity/.
59. Lee, D.D.; and Seung, H.S. Algorithms for non-negative matrix factorization. Advances in Neural
Information Processing Systems, Denver, CO, USA: Neural Information Processing Systems Foundation,
2001, pp. 556-562.
60. Lee, S.M.; Kim, T.; Noh, Y.; and Lee, B. Success factors of platform leadership in web 2.0 service
business. Service Business, 4, 2 (2010), 89-103.
61. Legner, C. Do web services foster specialization? An analysis of commercial web service directories.
International Conference on Wirtschaftsinformatik, Wien, Austria: Association for Information Systems,
2009, pp. 67-76.
62. Leisch, F. A toolbox for k-centroids cluster analysis. Computational Statistics & Data Analysis, 51, 2
(2006), 526-544.
63. Lin, A.; and Chen, N.-C. Cloud computing as an innovation: Percepetion, attitude, and adoption.
International Journal of Information Management, 32, 6 (2012), 533-540.
64. Lindman, J.; Kinnari, T.; and Rossi, M. Business roles in the emerging open-data ecosystem. IEEE
Software, 33, 5 (2016), 54-59.
65. Lindman, J.; Rossi, M.; and Tuunainen, V.K. Open data services: Research agenda. Hawaii International
Conference on System Sciences, Wailea, HI, USA: IEEE Computer Society, 2013, pp. 1239-1246.
39
66. Linzer, D.; and Lewis, J.B. poLCA: An R package for polytomous variable latent class analysis. Journal
of Statistical Software, 42, 10 (2011), 1-29.
67. Lusch, R.F.; and Nambisan, S. Service innovation: A service-dominant logic perspective. MIS Quarterly,
39, 1 (2015), 155-175.
68. Malhotra, A.; Gosain, S.; and Sawy, O.A.E. Absorptive capacity configurations in supply chains: Gearing
for partner-enabled market knowledge creation. MIS Quarterly, 29, 1 (2005), 145-187.
69. McNally, R.C.; Akdeniz, M.B.; and Calantone, R.J. New product development processes and new
product profitability: Exploring the mediating role of speed to market and product quality. Journal of
Product Innovation Management, 28, s1 (2011), 63-77.
70. Mizik, N.; and Jacobson, R. Trading Off Between Value Creation and Value Appropriation: The
Financial Implications of Shifts in Strategic Emphasis. Journal of Marketing, 67, 1 (2003), 63-76.
71. Mueller, B.; Viering, G.; Legner, C.; and Riempp, G. Understanding the economic potential of service-
oriented architecture. Journal of Management Information Systems, 26, 4 (2010), 145-180.
72. Muffatto, M.; and Roveda, M. Product architecture and platforms: A conceptual framework. International
Journal of Technology Management, 24, 1 (2002), 1-16.
73. Munaiah, N.; Kroh, S.; Cabrey, C.; and Nagappan, M. Curating GitHub for engineered software projects.
Empirical Software Engineering, 22, 6 (2017), 3219-3253.
74. Murphy, M.; and Sloane, S. The rise of APIs. Techcrunch, 2016, Retrieved 8 October, 2019:
https://techcrunch.com/2016/05/21/the-rise-of-apis/
75. Nambisan, S.; and Sawhney, M. Orchestration processes in network-centric innovation: Evidence from
the field. Academy of Management Perspectives, 25, 3 (2011), 40-57.
76. Niculescu, M.F.; Wu, D.; and Xu, L. Strategic intellectual property sharing: Competition on an open
technology platform under network effects. Information Systems Research, 29, 2 (2018), 498-519.
77. Nüttgens, M.; and Iskender, D. Business models of service-oriented information systems - A strategic
approach towards the commercialization of web services. Wirtschaftsinformatik, 50, 1 (2008), 31-38.
78. Oh, J.; Koh, B.; and Raghunathan, S. Value appropriation between the platform provider and app
developers in mobile platform mediated networks. Journal of Information Technology, 30, 3 (2015), 245-
259.
79. Panzar, J.C.; and Willig, R.D. Economies of scope. American Economic Review, 71, 2 (1981), 268-272.
80. Parker, G.; Van Alstyne, M.; and Jiang, X. Platform ecosystems: How developers invert the firm. MIS
Quarterly, 41, 1 (2017), 255-266.
81. Parker, G.G.; and Van Alstyne, M.W. Two-sided network effects: A theory of information product
design. Management Science, 51, 10 (2005), 1494-1504.
82. Podsakoff, P.M.; MacKenzie, S.B.; Lee, J.-Y.; and Podsakoff, N.P. Common method biases in behavioral
research: A critical review of the literature and recommended remedies. Journal of Applied Psychology,
88, 5 (2003), 879-903.
83. Reynolds, A.P.; Richards, G.; de la Iglesia, B.; and Rayward-Smith, V.J. Clustering rules: A comparison
of partitioning and hierarchical clustering algorithms. Journal of Mathematical Modelling and
Algorithms, 5, 4 (2006), 475-504.
84. Rossiter, J.R. The C-OAR-SE procedure for scale development in marketing. International Journal of
Research in Marketing, 19, 4 (2002), 305-335.
85. Rudmark, D. The practices of unpaid third-party developers – Implications for API design. Americas
Conference on Information Systems, Chicago, IL, USA: Association for Information Systems, 2013.
86. Santos, W. APIs show faster growth rate in 2019 than previous years. ProgrammableWeb, 2019,
Retrieved 8 October, 2019: https://www.programmableweb.com/news/apis-show-faster-growth-rate-
2019-previous-years/research/2019/07/17.
87. Schreieck, M.; Wiesche, M.; and Krcmar, H. Design and governance of platform ecosystems - Key
concepts and issues for future research. European Conference on Information Systems, Instanbul, Turkey:
Association for Information Systems, 2016, pp. 1-20.
88. Selander, L.; Henfridsson, O.; and Svahn, F. Capability search and redeem across digital ecosystems.
Journal of Information Technology, 28, 3 (2013), 183-197.
89. Setia, P.; Rajagopalan, B.; Sambamurthy, V.; and Calantone, R. How peripheral developers contribute to
open-source software development. Information Systems Research, 23, 1 (2012), 144-163.
90. Shi, Z.; and Whinston, A.B. Network structure and observational learning: Evidence from a location-
based social network. Journal of Management Information Systems, 30, 2 (2013), 185-212.
91. Simon, H.A. The architecture of complexity. Proceedings American Philosophical Society, 106, 6 (1962),
467-482.
92. Sivo, S.A.; Saunders, C.; Chang, Q.; and Jiang, J.J. How low should you go? Low response rates and the
validity of inference in IS questionnaire research. Journal of the Association for Information Systems, 7, 1
(2006), 351-414.
93. Smedlund, A. Value cocreation in service platform business models. Service Science, 4, 1 (2012), 79-88.
40
94. Song, P.; Xue, L.; Rai, A.; and Zhang, C. The ecosystem of software platform: A study of asymmetric
cross-side network effects and platform governance. MIS Quarterly, 42, 1 (2018), 121-142.
95. Song, P.; Xue, L.; Zhang, C.; and Rai, A. APIs in software platform: Implications for innovation and
imitation. International Conference on Information Systems, Seoul, Korea: Association for Information
Systems, 2017, pp. 1-11.
96. Stieglitz, S.; and Dang-Xuan, L. Emotions and information diffusion in social media - Sentiment of
microblogs and sharing behavior. Journal of Management Information Systems, 29, 4 (2013), 217-248.
97. Svahn, F.; Mathiassen, L.; and Lindgren, R. Embracing digital innovation in incumbent firms: How
Volvo Cars managed competing concerns. MIS Quarterly, 41, 1 (2017), 239-253.
98. Swink, M.; and Song, M. Effects of marketing-manufacturing integration on new product development
time and competitive advantage. Journal of Operations Management, 25, 1 (2007), 203-217.
99. The New York Times developer network. New York Times, 2019, Retrieved 8 October, 2019:
https://developer.nytimes.com/.
100. Tiwana, A. Platform Ecosystems: Aligning Architecture, Governance, and Strategy. Waltham, MA, USA:
Morgan Kaufmann, 2013.
101. Tiwana, A. Platform desertion by app developers. Journal of Management Information Systems, 32, 4
(2015), 40-77.
102. Tiwana, A.; Konsynski, B.; and Bush, A.A. Platform evolution: Coevolution of platform architecture,
governance, and environmental dynamics. Information Systems Research, 21, 4 (2010), 675-687.
103. Tiwana, A.; Konsynski, B.; and Bush, A.A. Research Commentary: Platform Evolution: Coevolution of
Platform Architecture, Governance, and Environmental Dynamics. Information Systems Research, 21, 4
(2010), 675-687.
104. Venkatraman, N. The concept of fit in strategy research: Towards verbal and statistical sorrespondence.
Academy of Management Review, 14, 3 (1989), 423-444.
105. Von Hippel, E.; and Katz, R. Shifting innovation to users via toolkits. Management Science, 48, 7 (2002),
821-833.
106. Wall, T.D.; Michie, J.; Patterson, M.; Wood, S.J.; Sheehan, M.; Clegg, C.W.; and West, M. On the
validity of subjective measures of company performance. Personnel Psychology, 57, 1 (2004), 95-118.
107. Wedel, M.; Böckenholt, U.; and Kamakura, W.A. Factor models for multivariate count data. Journal of
Multivariate Analysis, 87, 2 (2003), 356-369.
108. Xin, M.; and Levina, N. Software-as-a-service model: Elaborating client-side adoption factors.
International Conference on Information Systems, Paris, France: Association for Information Systems,
2008, pp. 1-12.
109. Xue, L.; Rai, A.; Song, P.; and Cheng, Z. Third-party developers' adoption of APIs and their continued
new app development in software platform: A competing risk analysis. Conference on Information
Systems & Technology, Houston, TX, USA: INFORMS, 2017.
110. Yoo, Y.; Henfridsson, O.; and Lyytinen, K. The new organizing logic of digital innovation: An agenda
for information systems research. Information Systems Research, 21, 4 (2010), 724-735.
111. Yu, S.; and Woodard, C.J. Innovation in the programmable web: Characterizing the mashup ecosystem.
International Conference on Service-Oriented Computing, Sydney, Australia: Springer, 2008, pp. 136-
147.
112. Zimmermann, S.; Müller, M.; and Heinrich, B. Exposing and selling the use of web services: An option to
be considered in make-or-buy decision-making. Decision Support Systems, 89 (2016), 28-40.
113. Zittrain, J.L. The generative internet. Harvard Law Review, 119, 7 (2006), 1974-2040.
41
Figures
Figure 1: Research model
Figure 2: Interaction between Economies of Scope in Production and Similarity to
Professional Services
Return on
investment
Mediation service
Professional
service
Open asset service
H1
H2
H3
Controls
•Functional quality
•Service innovativeness
•#employees
•Years with API provider
•Management level
Similarity of API design to
archetype:
Production Innovation
Target level of economies of scope in …
Diffusion
H4
42
Figure 3: Interaction between Economies of Scope in Production and Similarity to
Mediation Services
Figure 4: Interaction between Economies of Scope in Innovation and Similarity to
Open Asset
43
Tables
Platform
component
API element
Definition
Guiding
references
Partitioning
Function
API carries out information processing task
[7, 109, 110]
End customer access
API links developers to end customers
[60, 88, 102]
Systems
integration
Multi-channel access
Functionality or data is accessible through alterna-
tive channels
[61, 77]
Security
API supports data encryption (e.g. HTTPS)
[42, 63]
Decision
rights
End customer relationship
API maintains own relationship with end customers
[9, 37, 102]
Control
User authorization
API supports user authentication (e.g. key or token
based)
[42, 65]
Pricing
Subscription-based charg-
ing
API users are charged by subscription-oriented
logic
[61, 77, 112]
Transaction-based charg-
ing
API users are charged by transaction-oriented logic
[61, 77, 112]
Revenue sharing
API provider shares revenues with developers
[54, 78, 80]
Table 1. API characteristics, definitions, and guiding references
Archetype
Definition
Sources
Examples
Professional
service
API provides access to cloud-based IT resources
with direct or indirect charging that providers
traditionally distribute as installable software or
make accessible via browser-based interfaces.
[8, 29,
47, 61,
77, 108]
Amazon S3 API, SAP Anywhere
API, Google Maps API, Ac-
cuWeather Forecast API, FedEx
API, Expedia API
Mediation
service
API offers access to a two-sided platform’s
resources based on which third-party developers
design complementary service offerings for the
platform’s end customers.
[76, 80,
81, 88,
94]
Facebook Graph API, Twitter
Direct Message API, Youtube
Live Streaming API, Amazon
Product Advertising API,
LinkedIn API
Open asset
service
API gives free-of-charge access to organization-
internal IT resources with low integration effort.
[36, 48,
56, 65,
85]
New York Times API, DB Open
Data API, BBC Nitro API, NBA
Stats API, Github API
Table 2: API archetypes
44
Construct
Definition
Sources
Return on investment
The API’s return on investment relative to the company’s original
objectives for the API.
[18, 69]
Diffusion
Level of API awareness and adoption among third-party developers.
[89]
Target level of value crea-
tion mechanism
Level to which an API provider targets a mechanism of inter-
organizational value creation in a platform-based ecosystem.
[35]
Target level of
…
… economies of
scope in produc-
tion
The joint production of successive value creation stages is less costly
than producing separately if they are tightly interlinked.
[21, 79]
… economies of
scope in innova-
tion
Jointly innovating on two products is cheaper than independent inno-
vations on these two products.
[14, 75]
Similarity to API arche-
type
Three measures that represent the similarity to the “average repre-
sentative” of the three archetypes of API design (professional service,
mediation service, and open asset service)
[36, 75,
80]
Table 3: Constructs and definitions
API Design
Characteristic
Professional
Services (1)
Mediation
Services (2)
Open Asset
Services (3)
Cramer's V
Group
Comparisons
End Customer Access
0
66.67
4.35
0.76**
3-2**, 1-2**, 3-1
Multi-Channel Access
72.55
59.26
100
0.27**
3-2**, 1-2, 3-1**
End Customer Relationship
0.98
66.67
0
0.76**
3-2**, 1-2**, 3-1
Function
92.16
88.89
0
0.79**
3-2**, 1-2, 3-1**
Subscription-based Charge
97.06
11.11
0
0.91**
3-2, 1-2**, 3-1**
Transaction-based Charge
96.08
7.41
4.35
0.9**
3-2, 1-2**, 3-1**
User Authorization
98.04
100
65.22
0.48**
3-2**, 1-2, 3-1**
Security
68.63
74.07
21.74
0.36**
3-2**, 1-2, 3-1**
Revenue.sharing
0
18.52
0
0.4
3-2, 1-2**, 3-1
N (%)
67.10
17.76
15.13
** p < 0.01, * < 0.05
Table 4: Implementation of API Design Characteristics by API Cluster in %
45
API Design
Characteristic
Professional Service
Mediation Service
Open Asset Service
A
Salesforce Analytics
[2]
A
Dropbox
[23]
A
New York Times Search
[99]
Function
1
1: analytics function-
ality
1
1: file synchronization
and storage functionality
0
0: retrieval of article data
only
End customer
access
0
0: no marketing of
third-party apps to
end customers
1
1: marketing for apps that
integrate with Dropbox
API
0
0: no marketing of third-
party apps to end custom-
ers
Multi-channel
access
1
1: alternative browser
interface
1
1: browser-based access
and desktop integration
1
1: browser-based access to
articles
Security
1
1: HTTPS encryption
1
1: HTTPS encryption
0
1i: HTTPS encryption
End customer
relationship
0
0: salesforce has no
end customer relation-
ship
1
1: third-party app custom-
ers require a salesforce
subscription
0
0: third-party app custom-
ers don’t require NYT sub-
scription
User
authorization
1
1: authentication
model (API Key,
OAuth 2)
1
1: OAuth authentication
1
1: developer key required
Subscription-
based charging
1
1: requires paid
salesforce subscrip-
tion
0
0: API use does not re-
quire a
dropbox subscription
0
0: no charging
Transaction-
based charging
1
0i: no charges per API
call
0
0: no charges per API call
0
0: no charging
Revenue sharing
0
0: salesforce does not
share revenues
0
0: dropbox does not share
end customer revenues
with app developers
0
0: NYT does not share end
customer revenues with
app developers
A=Archetype; 1=Implementation, 0=No Implementation; i=nonconformance with archetype
Table 5: API Archetypes and Archetypical Examples
46
Table 6: Ordinal Logistic Regression Results
Similarity to Design Archetype and Level of
targeted economies of scope on production
Cumulative Probability for Minimum Level of
Goal Attainment for API ROI
low
moderate
high
very high
High Similarity to Professional Service &
High levels of economies of scope in production
0.99
0.93
0.68
0.33
High Similarity to Professional Service &
Low levels of economies of scope in production
0.95
0.78
0.36
0.11
Low Similarity to Professional Service &
High levels of economies of scope in production
0.95
0.8
0.39
0.13
High Similarity to Mediation Service &
High levels of economies of scope in production
0.98
0.89
0.57
0.24
High Similarity to Mediation Service &
Low levels of economies of scope in production
0.93
0.72
0.29
0.08
Low Similarity to Mediation Service &
High levels of economies of scope in production
0.97
0.86
0.5
0.19
Table 7: Predicted Probabilities for Ordinal Logistic Regression
Hypo-
thesis
Variables
Model 1a API ROI
(main effects)
Model 1b API ROI
(full model)
Coefficients
Exp(β)
(Odd Ratio)
Coefficients
Exp(β)
(Odd Ratio)
Economies of scope in production
0.20 (0.19)
1.23
0.23 (0.2)
1.26
Similarity professional service archetype
0.12 (0.16)
1.13
0.16 (0.17)
1.17
Similarity mediation archetype
-0.16 (0.16)
0.85
-0.23 (0.17)
0.79
H1
Economies of scope in production *
similarity professional service archetype
0.45** (0.18)
1.57
H2
Economies of scope in production *
similarity mediation archetype
0.37* (0.18)
1.45
Functional quality
1.15** (0.23)
3.14
1.17** (0.24)
3.22
Service innovativeness
-0.08* (0.00)
0.66
-0.37 (0.20)
0.69
Employees API provider
-0.06 (0.13)
0.95
-0.07 (0.14)
0.93
Respondent API Affiliation
0.72 (0.47)
2.06
0.71 (0.48)
2.04
Respondent years API provider
0.01 (0.16)
1.01
-0.03 (0.16)
0.97
R2
0.26
0.30
Δ R2
0.04*
N = 152; ** p < 0.01, * p < 0.05
Reported are standardized beta values. Standard errors in parentheses.
47
Table 8: Negative Binomial Regression Results
Hypo-
thesis
Variables
Model 2a API Diffusion
(main effects)
Model 2b API Diffusion
(full model)
Coefficients
Exp(β)
Coefficients
Exp(β)
Economies of scope in innovation
-0.34 (0.26)
0.71
-0.32 (0.22)
0.72
Similarity to mediation archetype
-0.08 (0.23)
0.92
0.00 (0.19)
1.00
Similarity to open asset archetype
-0.22 (0.22)
0.80
-0.24 (0.19)
0.79
H3
Economies of scope in innovation *
similarity to open asset archetype
0.45* (0.22)
1.57
H4
Economies of scope in innovation *
similarity to mediation archetype
0.07 (0.2)
1.08
Functional quality
0.29 (0.28)
1.33
0.29 (0.24)
1.33
Service innovativeness
0.01 (0.29)
1.01
-0.02 (0.24)
0.98
Employees API provider
0.35 (0.21)
1.42
0.36* (0.18)
1.43
Respondent API Affiliation
-1.19 (0.65)
0.30
-1.14 (0.63)
0.32
Respondent years API provider
-0.11 (0.22)
0.90
-0.07 (0.19)
0.94
R2
0.25
0.30
Δ R2
0.05**
N = 152; ** p < 0.01, * p < 0.05
Reported are standardized beta values. Standard errors in parentheses.
1
Fostering Value Creation with Digital Platforms: A
Unified Theory of the Application Programming
Interface Design
- Online Appendix -
APPENDIX A - SYNTHESIS OF API TYPOLOGIES ........................................................ 2
APPENDIX B - SURVEY INSTRUMENT AND GUIDING REFERENCES ...................... 3
APPENDIX C - EXPLORATORY AND CONFIRMATORY FACTOR ANALYSIS ......... 4
APPENDIX D - DESCRIPTIVE STATISTICS AND CORRELATIONS ........................... 5
APPENDIX E - NUMBER OF CLUSTERS (AVERAGE SILHOUETTE VALUES) .......... 6
APPENDIX F - NUMBER OF CLUSTERS (DUNN-INDEX) .............................................. 6
APPENDIX G - AGREEMENT BETWEEN CLUSTERING METHODS .......................... 7
REFERENCES .................................................................................................................... 7
2
Appendix A - Synthesis of API Typologies
Author
Method
API classification (description)
Mapping
[10]
Longitudinal
study of web
service
directories
Web services as core competency (chargeable web services by
professional service providers)
Professional
services
Complementary Web services (Offered to business partners;
complementary to core product)
Mediation
services
“Gadget” Web services (free of charge; exploratory nature)
Open asset
services
[5]
Visual analysis of
API network
Create new revenue streams by offering access to already
existing digital information
Professional
services
Make it possible for third parties to build entirely new digital
applications and services by creating “mashups”
Open asset
services
Digital platform APIs (businesses around areas such as social,
mapping, search, online payment, image sharing, video, and
messaging)
Mediation
services
[9]
Multiple case study
approach
Open innovation tool (engage third-party developers and
leverage creativity of people working beyond boundaries of API
provider’s organization)
Open asset
services
Business scaling tool (in business-to-business environment API
can be used as a tool to scale integration capabilities with clients
and partners)
Professional
services
Tool to reach new audiences (leverage resources of third-party
developers to research user groups)
Mediation
services
[13]
Conceptu
al model
and
cases
Strengthening the core business (free access to resources in
order to support or improve core offering)
Mediation
services
Distribution of fee-based services (APIs offer fee-based access
to a service provider’s core resources)
Professional
services
[1]
Topic modeling of
API descriptions
Enablers – Capability (increase capability of customer by
providing functionality such as cloud resource management,
mining cryptocurrency or shipping logistics)
Professional
services
Enablers - Information resources (give access to data or
information resources)
Open asset
services
Experience providers (allows the API developer to personalize,
or interoperate with a product or a Software-as-a-Service)
Professional
services
3
Appendix B - Survey Instrument and Guiding References
Construct
Measurement
Guiding
references
If your company offers multiple public APIs, please select the API with the highest importance for your
company and relate all questions in this survey to the selected API.
Economies of
Scope:
Please indicate the extent to which the following statements describe your
company’s API strategy (1: not at all - 5: to a very large extent).
Economies of
scope in
production
By modularizing our IT resources (applications, data, or
infrastructure) and providing API access to modules, …
• (prod_1) we allow flexible integration of our IT resources into an
external developer’s IT system.
• (prod_2) we facilitate adaptation of our IT resources to an external
developer’s IT system.
• (prod_3) we enable deep integration of our IT resources into an
external developer’s IT system.
(self-developed)
[4, 7, 8]
Economies of
scope in
innovation
By exposing internal IT resources (applications, data, or
infrastructure) to external developers, …
• (inno_1) we tap into the inventive capacities of the external
developer community.
• (inno_2) we exploit the creative potential of external developers.
• (inno_3) we enhance our innovation capabilities.
(self-developed)
[2, 8, 12]
Dependent
variable:
Please rate the relative performance of your company’s API (1: strongly disagree -
5: strongly agree)
API return on
investment
• (roi) The API is very successful in terms of return on investment
relative to your company’s original objectives for the API.
Adapted from
[3, 11]
Controls:
Functional
quality
Our company’s API …
• (fq_1) offers some unique features compared to competing APIs.
• (fq_2) is clearly superior to competing APIs in terms of meeting
developers’ needs.
• (fq_3) is of higher quality than competing APIs.
[15]
Service
innovativeness
Please rate the degree to which the API is …
• (si_1) very ordinary for our industry/very novel for our industry.
• (si_2) not challenging to existing ideas in our industry/challenging
to existing ideas in our industry.
• (si_3) not offering new ideas to our industry/ offering new ideas
to our industry.
[6]
API Provider
Employees
• Please estimate the number of employees at your API-providing
company.
[16]
Respondent
Years with API
provider
• Please indicate for how long you have been employed at the API-
providing company.
[14]
Respondent
API Affiliation
• Please indicate your affiliation (internal / API provider or external
/ service provider or consultancy).
[14]
4
Appendix C - Exploratory and Confirmatory Factor Analysis
Item
Factors
Loading
α
AVE
CR
EoS in
Production
Functional
Quality
Service
Innovativeness
EoS in
Innovation
API
ROI
prod_1
0.87
0.15
-0.01
0.11
-0.13
0.81***
0.82
0.60
0.82
prod_2
0.82
0.15
0.07
0.2
0.05
1***
prod_3
0.79
0.00
0.12
0.19
0.27
0.82***
fq_3
0.15
0.84
0.09
0.08
0.16
0.8***
0.80
0.59
0.81
fq_2
0.17
0.82
0.22
0.1
0.12
0.92***
fq_1
0.00
0.73
0.21
0.23
0.03
0.67***
si_2
0.15
0.10
0.86
0.11
0.00
0.9***
0.80
0.59
0.81
si_3
0.07
0.11
0.83
0.18
0.06
0.82***
si_1
-0.06
0.31
0.76
0.03
-0.02
0.74***
inno_2
0.19
0.06
0.05
0.86
0.02
1.02***
0.79
0.58
0.80
inno_1
0.19
0.16
0.07
0.83
0.02
0.97***
inno_3
0.09
0.16
0.21
0.72
0.07
0.68***
roi
0.09
0.25
0.02
0.07
0.94
1.08***
N = 152; ** p < 0.01
MSA = 0.75; Bartlett-test of specificity: χ² = 1016.73, p < 0.01; principal component analysis; varimax-rotation; The bold
values indicate the attribution of the variables to one of the five factors.
EoS in Production = Economies of Scope in Production; EoS in Innovation = Economies of Scope in Innovation; α =
Cronbach’s Alpha; AVE = Average Variance Explained; CR = Composite Reliability
5
Appendix D - Descriptive Statistics and Correlations
Variable
Mean
Min
Max
SD
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(1) API ROI
3.89
1
5
1.08
(2) API Diffusion
57.93
3
1736
200.00
0.05
(3) Economies of Scope in
Innovation
3.67
1
5
0.99
0.17
-0.04
0.76
(4) Economies of Scope in
Production
3.95
1
5
0.97
0.20
-0.17
0.40**
0.78
(5) Functional Quality
3.79
1
5
0.89
0.37**
0.07
0.35**
0.28**
0.77
(6) Service Innovativeness
3.62
1
5
0.91
0.11
0.03
0.29**
0.17
0.41**
0.77
(7) Similarity Professional
Service Archetype
0.31
0
1
0.32
0.01
0.12
0.11
0.01
-0.13
-0.05
(8) Similarity Mediation
Service Archetype
0.49
0
1
0.20
-0.09
-0.20
0.02
0.22*
-0.02
0.00
0.04
(9) Similarity Open Asset
Archetype
0.43
0
1
0.17
-0.04
-0.04
0.10
0.03
0.15
0.21*
-0.24*
0.09
(10) Employees API Provider
2971.01
1
300000
24725.65
0.03
0.42**
0.02
-0.01
0.02
0.1
0.06
-0.20
0.05
(11) Respondent Affiliation
1.15
1
2
0.36
0.18
0.01
0.07
0.17
0.11
0.13
0.00
0.03
-0.04
0.21*
(12) Respondent Years API
Provider
5.97
1
21
4.86
-0.02
-0.01
0.01
0.03
-0.04
-0.06
0.16
0.13
-0.24*
0.03
-0.13
N = 152,** p < 0.01, * < 0.05
Bold values indicate the square root of the correlation for checking the Fornell-Larcker criterion.
6
Appendix E - Number of Clusters (Average Silhouette Values)
Appendix F - Number of Clusters (Dunn-Index)
7
Appendix G - Agreement between Clustering Methods
Clustering Algorithm (Distance Measure)
Cramer’s V (Chi-Square)
Percent Agreement
(1)
(2)
(3)
(1)
(2)
(3)
(1) Spherical K-Means (Cosine)
(2) Numeric Optimization (Jaccard)
0.99**
0.99
(3) K-Medians (Hamming)
0.83**
0.84**
0.91
0.91
(4) Partitioning Around Medoids (Hamming)
0.81**
0.82**
0.94**
0.89
0.90
0.97
N = 152,** p < 0.01, * < 0.05
Significance levels refer to the significance of the Chi-Square test statistic.
References
1. Amin, M.M.H. A Topic Modeling Approach to Categorizing API Customer Value Propositions. Carleton
University, 2016, Retrieved 8 October, 2019: https://curve.carleton.ca/b32eef3e-0312-4dcd-ad1e-
084240bbf745.
2. Bresnahan, T.F.; and Trajtenberg, M. General purpose technologies ‘engines of growth’? Journal of
Econometrics, 65, 1 (1995), 83-108.
3. Cooper, R.G. The dimensions of industrial new product success and failure. Journal of Marketing, 43, 3 (1979),
93-103.
4. D'Aveni, R.A.; and Ravenscraft, D.J. Economies of integration versus bureaucracy costs: Does vertical
integration improve perfoermance? Academy of Management Journal, 37, 5 (1994), 1167-1206.
5. Evans, P.C.; and Basole, R.C. Revealing the API ecosystem and enterprise strategy via visual analytics.
Communations of the ACM, 59, 2 (2016), 26-28.
6. Fang, E. Customer participation and the trade-off between new product innovativeness and speed to market.
Journal of Marketing, 72, 4 (2008), 90-104.
7. Garcia, S.; Moreaux, M.; and Reynaud, A. Measuring economies of vertical integration in network industries:
An application to the water sector. International Journal of Industrial Organization, 25, 4 (2007), 791-820.
8. Gawer, A. Bridging differing perspectives on technological platforms: Toward an integrative framework.
Research Policy, 43, 7 (2014), 1239-1249.
9. Hatvala, A. Open innovation opportunities and business benefits of web APIs: A case study of Finnish API
providers. Aalto University, 2016, Retrieved 8 October, 2019: http://urn.fi/URN:NBN:fi:aalto-201609083660.
10. Legner, C. Do web services foster specialization? An analysis of commercial web service directories.
International Conference on Wirtschaftsinformatik, Wien, Austria: Association for Information Systems, 2009,
pp. 67-76.
11. McNally, R.C.; Akdeniz, M.B.; and Calantone, R.J. New Product Development Processes and New Product
Profitability: Exploring the Mediating Role of Speed to Market and Product Quality. Journal of Product
Innovation Management, 28, s1 (2011), 63-77.
12. Nambisan, S.; and Sawhney, M. Orchestration processes in network-centric innovation: Evidence from the field.
Academy of Management Perspectives, 25, 3 (2011), 40-57.
13. Nüttgens, M.; and Iskender, D. Business models of service-oriented information systems - A strategic approach
towards the commercialization of web services. Wirtschaftsinformatik, 50, 1 (2008), 31-38.
14. Podsakoff, P.M.; MacKenzie, S.B.; Lee, J.-Y.; and Podsakoff, N.P. Common method biases in behavioral
research: A critical review of the literature and recommended remedies. Journal of Applied Psychology, 88, 5
(2003), 879-903.
15. Swink, M.; and Song, M. Effects of marketing-manufacturing integration on new product development time and
competitive advantage. Journal of Operations Management, 25, 1 (2007), 203-217.
16. Tiwana, A. Platform desertion by app developers. Journal of Management Information Systems, 32, 4 (2015),
40-77.
